Drieux and the others who took the time to answer me: Thank you very much for your clear explanation. I am indeed in this for the long haul, so will accept your advice to spend the extra time now and write modules. I had actually settled on the last approach you mention, but now I see its limitations.
If I may summarize -- and please correct me if this is wrong -- there is indeed no way to textually include one file inside another, like #include in C. The text file is the compilation (lexical) unit, and the only way to import lexical symbols is via the module (package) mechanism. Thanks again. "Drieux" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > On Wednesday, Sep 18, 2002, at 05:12 US/Pacific, Cricker wrote: > > > Thanks, but I thought that modules were for submitting to CPAN. > > a reasonable approach, in the long run, since you will find it > easier to install for both yourself and everyone else, IF you > build them in a way that is CPAN 'ready' as it were. > > > Don't I > > have to go through all the @ISA and Exporter:: stuff if I write a > > module? > > yes and no. If you want to remain in a strictly 'functionalist' > approach - then you CAN get into the %EXPORT_TAGS approach where > you allow groups of functions to be exported together - as is the > way with many perl modules from the CPAN. Alternatively you can > just make a 'utility class' with all methods and no embedded data > so that everything "hangs" off an 'object' like entity > > my $foo = new FOO::BAR ; > my $hash_ref = $foo->get_hash_ref_oh_stuff(@list_shrugged); > > which does not require the 'Exporter stuff'.... > > > I would like to get away with something simpler. > > well 'simpler is as simpler does'.... > > as it says, "my ongoing war with Perl Modules" is at: > > http://www.wetware.com/drieux/CS/lang/Perl/PM/ > > and I offer a 'case study' on why I personally > perfer to follow the perl documentation and start > with h2xs - cf: > > http://www.wetware.com/drieux/CS/Proj/PID/ > > since you get the quick introduction into the Maker > utilities and the standard approach that will allow > you to the standard > > perl Makefile.pl > make > make test > make install > > Since at some point in the process you will want to > actually 'install the module' so that it can be > used - and that means one of three strategies > > a) let perl put it in the site_perl on the host > > b) have your own ~/lib/perl5 - and hence a simple > modification to the above that defines all of that. > this will require the usual > > b1: use lib "$ENV{HOME}/lib/perl5" > b2: setting the PERL5LIB environmental variable > > c) The MacApp Approach - that you FOO.pm be in the > same directory as the executable so that it will > be found based upon perl having been built to check > "." for the other modules in the @INC - but this means > being IN that directory when you fire up your app > > of the three, the first is the simplest. > > Remember the moment that it makes sense to move into doing > 'perl libraries' - it's time to just get at home with doing > them as Perl Modules - and take the extra time to do it right > the first time - so that you can maintain them over the course > of time... > > > ciao > drieux > > --- > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
