Thank you for your response. This is exactly what I was looking for. I wanted to know if there was another way to do it, and you pointed out that there is, but that it is not recommended and therefore not the preferred way.

I am curious though, if every function is going to be available (exported) is there a reason not to put them in package main?

You have it backwards. It is not recommended because it is not preferred, and not vice versa.

The next question is why it is not preferred. Several reasons:

1. If a script uses multiple modules that autoexport lots of stuff, it quickly gets hard to figure out where any given function came from. Give users the option to enforce sanity by documenting what came from where.
2. When independent modules put things into package main, it becomes very easy for private functions in one to conflict with private functions in another. Tracking down and resolving these conflicts grows more complex rapidly as the number of functions and files grows. (With 5 files you only have 1/4 the number of possible lines of conflict as you do with 10.) Putting each file in its own package reduces the damage from such internal conflicts.
3. It is preferred that you not export every function. Good modularity in procedural code is to have each module have a simple API. A ton of exported functions is a very complex API.
There are more reasons, plenty of them, but those will do for now. If you want the rest, along with plenty of other good advice, I can highly recommend Code Complete. (No, that is not a Perl book. But good programming technique is not Perl-specific.)

Yes, you can do what you ask for. Perl gives you enough rope to hang yourself. But that doesn't mean that you should do it...

UPDATE: I used the word "recommended" where I really meant "preferred".

...if every function is going to be available (exported) is there a reason not to put them in package main?

One reason could be code reuse. If the same functions are used across several scripts, you at minimum save a little typing by keeping them in a separate file where they can be pulled in by all the scripts that need them.




Dave

I think you missed the point here. We are already discussing a separate module that can be used by any script. The question is, if that module exports every function within, why not simply make the package name 'main' and not bother exporting?

The answer is: because that forces your decision upon all users of the module. If you at least use a separate package name I can avoid your auto-exportation of everything by doing: use YourMod();. Or maybe I want to use your module from another package (have your module export into a different namespace). If you write your module to simply define everything inside of package 'main', you've removed all my options.