in reply to Module 'use' chains

First of all, this is a really bad idea. There is a reason that Exporter recommends not sticking stuff into @EXPORT. And that reason is that when you have a problem with a function, you've just made it very hard to figure out where that function is from.

But if you wish to do this, and if every one of the modules used Exporter, then this module will do what you want.

package Include; use base Exporter; use A; push @EXPORT, @A::EXPORT; use B; push @EXPORT, @B::EXPORT; use C; push @EXPORT, @C::EXPORT; 1;
But again. This is a bad idea. Read Code Complete and muse on "loose coupling" to understand why.

Replies are listed 'Best First'.
Re^2: Module 'use' chains
by merlyn (Sage) on Aug 10, 2006 at 03:01 UTC
      Mine would work, with caveats. Yours works without caveats. So you have the more effective bad solution. merlyn++
Re^2: Module 'use' chains
by Vaati (Sexton) on Aug 10, 2006 at 02:29 UTC
    Keen, thank you for your response. It was very helpful. I know this is dangerous, and in truth I'd rather not do it. However, I've run into a scenario where I in herited a 4K+ line script. I'm in the process of refactoring it now and have busted it up into about 8 modules. The reason why I thought this would be useful is becuase I can't figure out how to "deeply" compile test this. So "undefined" subroutines are going to drive me to heroin at this point becuase perl -c always reports good. And it seems that if I copy/paste the entire chain of 'uses' into all 8 modules it gets really, really confused and can't find all the subs.

      Sounds to me like you have done a good job in starting to modularise a script, but that some further redesign is required.

      Without knowing the exact problem, I can't be sure or specific, but if it were me I would sit down with a pad and paper (or some equivalent) to try to re-think the process flow of the script - and how I can make the modules more modular.

      -=( Graq )=-