Re: To module or not?

[Fletch]

The point of all the extra Exporter gunk as well as the package declaration is to put the code into its own separate namespace. Sure for your simple one sub it's overkill, but when you get more and more subs it'll make your life much easier.

• You'll be able to selectively import specific subs (or sets of subs via tags) into your namespace rather than getting everything from the file unconditionally
• You can specifically refer to different subs which may have the same name (not an issue here, but what if you had something with a more common name, e.g. both MyModule::send and MyOther::send)
• You'll already have started establishing good habits of compartmentalizing your code
• The maintenence programmer who follows in your footsteps n months from now won't curse your name and invest in a voodoo doll.

[bradcathey]

A follow up question might be: is there a way to have global variable shared between the main::space and the module::space so I don't have to keep passing the same values over and over? (I know, not a good idea, but just for the sake of discussion)

So, instead of:

#MAIN:
my $foo = "aaaaaaa";
my $bar = "bbbbbb";

print add_strings ($foo, $bar);

Be able to just have:

#MAIN:
my $foo = "aaaaaaa";
my $bar = "bbbbbb";

print add_strings ();

#MODULE:
our ($foo, $bar); #this might be make-believe

add_strings {
   my $newstring = $foo . $bar;
   return ($newstring);
}

[Fletch]

You could always reference $main::foo et al, but you'd have to use our $foo in main rather than my (lexicals not living in the symbol table and all).

But yeah, not a good idea. Action at a distance, and what not.