SPUG: Interdependance of package subroutines

Jay Scherrer jay at scherrer.com
Thu May 19 13:31:24 PDT 2005


Ken,
A while back, I'd say 2001, I had created what was to be a monstrous
program for doing Income Taxes. Although this was done using Perl::Tk
the idea was the same as yours. I had created a main package for the
1040 operations and since there were a total of over 250 schedules and
forms used I then grouped specific operations (functions) within similar
sections otherwise called sub packages branching from the main package.
Then, as I created the different skins or GUI's for the user interface,
I would save these into a separate files (named accordingly). This is
were I found the real use of "require" instead of "use". Because, I
wouldn't know if a user really needed to use a schedule C or not until
further into the application. Perl will only compile a required file at
time of use and not before. So if they never ended up using this
required file, it would never be called or compiled. But another use for
require I had found was that at run time Perl will also check to see if
your whole listing of files are complete or at least called against your
main listing. This makes for a great "Is everybody accounted for" type
checking. I hope this make sense? If you want to share some ideas let me
know. My antiquated program can still be found at
<http://tenforty.sourceforge.net>.

Jay Scherrer

On Thu, 2005-05-19 at 11:36 -0700, Ken Clarke wrote:
> Hi Folks,
> 
>     I'm building a library of subroutines, separated into functionally 
> grouped packages, for use in CGI scripts and cron jobs.  I'm finding that as 
> the library grows more and more I want subroutines from one package to be 
> available for use in another package, so I'm either calling them by their 
> package qualified names [ eg my $result_hashref = 
> &MyPackage::my_sub(\%sub_args); ], or if they've been imported into package 
> main, directly from there [ eg my $result_hashref = 
> &main::my_sub(\%sub_args); ].
> 
>     I would appreciate hearing your comments on the wisdom of this strategy 
> from an architectural standpoint.  Testing on various platforms shows that 
> everything works as intended but I'm getting an uneasy feeling that there 
> may be pitfalls which I am not seeing.
> 
>     I'd also appreciate recommendations for articles, books etc which 
> examine architectural/structural issues of medium to large scale 
> applications.
> 
>     Thanks for your time.
> 
> >> Ken Clarke
> >> Contract Web Programmer / E-commerce Technologist
> >> www.PerlProgrammer.net
> 
> _____________________________________________________________
> Seattle Perl Users Group Mailing List  
>      POST TO: spug-list at pm.org
> SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list
>     MEETINGS: 3rd Tuesdays, Location: Amazon.com Pac-Med
>     WEB PAGE: http://seattleperl.org/



More information about the spug-list mailing list