http://www.perlmonks.org?node_id=1016369


in reply to Best way to manage package versions?

Any time there is a team of more than one the following disciplines should be enforced (IMHO):

I'm not sure what you mean by this:

the left hand expression makes no sense in context with the right hand expression.

If you are writing modules there is one approach, if you are writing (for lack of better word) libraries of functions there is another. To my way of thinking modules are self contained cohesive units that mimic an object oriented system. (whew!) I stop just short of making parallels between Perl modules and C++ (or Java) classes. They are not quite the same although there is some resemblance.

If I create a file "Foo.pm" and put in it:

sub a { print "letter a"; } sub b { print "letter b"; } sub mother_mary { print "whispers softly"; } 1;
and in a Perl script use:
require Foo; mother_mary(); print " "; b(); print "\n";
When I run the above code I get:
$ perl require.pl whispers softly Letter B
BUT! if I change this to a true module such that:
package Foo; sub a{ print "Letter A"; } sub b{ print "Letter B"; } sub mother_mary { print "whispers softly"; } 1;
something completely different happens:
$ perl require.pl Undefined subroutine &main::mother_mary called at require.pl line 3.
something completely different happens. The three subs in "Foo.pm" are no longer in the main context but become part of their own context "Foo". You can get around that by using Exporter and friends and possibly using export tags to group functions together.

My personal preference though would be to have a code review and figure out what groups of functions should be grouped together as object oriented modules. Maybe you can make your code much more organized and have more effective units for unit testing. Key thought being make your modules as self contained as possible.


Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg