in reply to alternative way to subs

There are several ways to do that, as always... one elegant way of doing that is using the AutoLoader (as e.g. POSIX does it) together with Exporter. To use that, you have to make up a package file (say, General.pm)

package General; use AutoLoader qw(AUTOLOAD); use Exporter; # functions your main script might want to import our @EXPORT_OK = qw( func1 func2 ... ); 1;

and wrap the content of each file into a subroutine:

original:

#!/usr/bin/perl # file prog1.pl # main program my ($arg_a, $arg_b) = @ARGV; ; # ... more perl code # end main

wrapped:

#!/usr/bin/perl # file func1.al package General; # the function must be compiled into its package. sub func1 { # main program my ($arg_a, $arg_b) = @_; ; # ... more perl code # end main } unless (caller) { func1(@ARGV); } 1; # <-- important!

The package file General.pm lives anywhere where perl can find it. Make a directory ./auto/General/ in the directory where General.pm lives and stuff the wrapped function files (*.al files) there. Write the file ./auto/General/autosplit.ix

package General; # optionally put your subs here to predeclare them at package loading sub func1 ; 1; # last line, important

That's it. Now you can use General.pm in your main script

#!/usr/bin/perl use General qw(func1 otherfunc); # functions from General you want to +call directly my $result = func1($arg_a, $arg_b);

and each function file will be compiled on demand, that is, only if you actually are calling its function.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Replies are listed 'Best First'.
Re^2: alternative way to subs
by Zen (Deacon) on Apr 30, 2008 at 14:56 UTC
    I'm not familiar with this strategy. Are you creating two packages named General? I see it declared twice.

      A package declaration just says "Unless I specifically say otherwise by qualifying them, any symbol table references (subroutine definitions, global (package) variable references via our, etc) I make should be understood to be going into this package until I say otherwise or the current scope ends". There's no written-in-stone correspondence between any given package and only one file. If you really wanted to you could have n different files all putting things into the same one package, or one file which puts subs in m different packages. Convention and normal usage tends to be one-package-per-file, but that's again convention not a requirement.

      The cake is a lie.
      The cake is a lie.
      The cake is a lie.

        Thanks for clarifying. I generally see this done all in one .pm, which is why I asked. I'm not sure what his strategy is by separating out the exporter lines from the package. I've always seen it done by putting that in the same .pm as the package. This is a design question, not a question of the perl validity.