Vaati has asked for the wisdom of the Perl Monks concerning the following question:

Hey monks got a question. Is there a way to create a communal 'header' module. I've been playing with this for a while and can't get it to work. Basically what I want to do is something similar to the this:
package Include.pm use A.pm use B.pm use C.pm 1;
Then in my script:
use Include; funcA(); ## Defined in A.pm funcB(); ## Defined in B.pm funcC(); ## Defined in C.pm
What I've been trying to find is a way to have Include.pm export not only what it defines but what it has 'used' as well. I haven't been able to get this to work. Is there even a way to do this? I humbly seek your wisdom. Thanks,

Replies are listed 'Best First'.
Re: Module 'use' chains
by tilly (Archbishop) on Aug 10, 2006 at 02:03 UTC
    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.
        Mine would work, with caveats. Yours works without caveats. So you have the more effective bad solution. merlyn++
      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 )=-

Re: Module 'use' chains
by davorg (Chancellor) on Aug 10, 2006 at 08:14 UTC

    I think you're looking for Toolkit.pm.

    --
    <http://dave.org.uk>

    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg

      Thank you all very much for your help, it has been invaluable. I really appreciate it. PS: BTW Randal congrats on the OpenSource award.
Re: Module 'use' chains
by bbfu (Curate) on Aug 10, 2006 at 05:24 UTC

    A simpler method is to just leave off the package line in your Include module. The module automatically starts in the package of the caller, and thus the chain-included modules will automatically export to the correct place.

    bbfu
    Black flowers blossom
    Fearless on my breath

      That will only work the first time use is called. Replace
      use Include;
      with
      BEGIN { do 'Include.pl'; }

      Perl really works like that? (Tests.) Ugh.

      But note that that only works if the package is used only from within one package.

        You're right. I should have tested it more thoroughly.

        bbfu
        Black flowers blossom
        Fearless on my breath

Re: Module 'use' chains
by sgt (Deacon) on Aug 10, 2006 at 20:29 UTC

    actually this question is perl hack #34 by Damian Conway; it mentions Filter::Macro and Toolkit

Re: Module 'use' chains
by Moron (Curate) on Aug 11, 2006 at 09:21 UTC
    If the intention is to site-extend the set of core modules then I'd be more inclined to require a file called something like SiteCore.pl and maintain a single set of use statements there, the requirement of this file being then a project standard. This is also a way to manage your own software that has to run on old as well as new perl versions where the core set has changed in between.

    -M

    Free your mind