Re^2: Re-exporting dynamically-included variables

That would be the obvious solution if the namespace were static, but (as explained more extensively in "use"ing from dynamic namespace) the idea here is that I want to be able to derive a Foo::Module and a Bar::Module from Base::Module which reference Foo::Module::Config and Bar::Module::Config (respectively) instead of Base::Module::Config (since the Foo and Bar applications would, naturally, each want their own configurations).

Comment on Re^2: Re-exporting dynamically-included variables Select or Download Code

Replies are listed 'Best First'.
Re^3: Re-exporting dynamically-included variables by tilly (Archbishop) on Jan 10, 2009 at 00:14 UTC
My attitude is that that is exactly the sort of situation that eval exists for. Just be sure to check for $@ and die if you've trapped a real error.	[reply]
Re^4: Re-exporting dynamically-included variables by dsheroh (Monsignor) on Jan 10, 2009 at 00:51 UTC
Changing the `eval 'require ' . config_module;` to `eval 'use ' . config_module . ' qw( %conf )';` certainly simplified things considerably. I ran into a situation earlier on where I was only able to get `require` to work, not `use`, but it apparently no longer applies. Thanks for the nudge towards switching back to `use`! After trying that, I was still seeing the same failure mode, so I started working on a minimal failing case that I could post in full instead of just the excerpts previously posted and, of course, it turned out that the real issue was in some of the "irrelevant" code I'd left out... There was another module which used `%conf` and its `require/use` was being `eval`ed before the config module. Which explains why it was getting a different `%conf` than the code which was loading after the config module. Proof once again of the value in creating a minimal failing case...	[reply] [d/l] [select]