Package Proliferation

throop has asked for the wisdom of the Perl Monks concerning the following question:

Why have a separate package for every file in a project?

A current project's goal is to take two sets of requirements (old and new). Find the best matches between them. Major subtasks are:

Read the requirements in, sanity check
Construct complex weighting scheme
Perform the match
Print out report tables

I'm putting each of these in a separate file; files run ~350 lines each.

All the tutorials and examples (e.g. perltoot) show a different package for each file (something like RqMatch::InSanity, RqMatch::Weight, RqMatch::Matches, RqMatch::Report). And the modules that I've downloaded from CPAN mostly follow this scheme.

Why? Why not just put them all in a single package? The project isn't large enough for naming collisions to be a problem.

Suppose I use the same package throughout. During development, when I notice that a file has grown large enough to become unwieldy, and has developed two separate themes, I just create a new file and move some of the functions / methods over there. I don't have to do any package-management to my existing files. But if I give the new file its own package, then I have to doublecheck all the places I've invoked those functions. What does it buy me?

Comment on Package Proliferation

Replies are listed 'Best First'.
Re: Package Proliferation by Corion (Patriarch) on Jun 19, 2011 at 15:54 UTC
Two reasons: files run ~350 lines each - organisation of topics And the modules that I've downloaded from CPAN mostly follow this scheme. - adherence to customs Now, as to why to put all the routines into separate packages, why not ask the author directly? I can, again, think of at least one reason, separation of concerns. Having the routines for data fetching and data reporting neatly separated helps testing and developping them in separation.	[reply]
Re: Package Proliferation by davido (Cardinal) on Jun 20, 2011 at 00:45 UTC
Keeping packages tied to files really helps me organize myself with respect to testing. It just makes life a whole lot easier if I know that these tests deal with this file, which contains this module, etc. The bigger the file gets, the more likely I am to forget to test something. Smaller files yield smaller test files, which, for me, enhances maintainability. The same goes for general maintenance. If each package contains a file, I don't need to remember where a particular package is. The file tells me. File modification dates are also meaningful; if the file hasn't been modified, neither has the package within. Some of this is mirrored by a good revision control system. But what does it hurt to keep things simple? Dave	[reply]
Re: Package Proliferation by wfsp (Abbot) on Jun 20, 2011 at 08:22 UTC
A few years ago I refactored a _one big script_ into packages (Make everything an object?). Four of them, actually, not a million miles away from your list. :-) While that post revolves around OO the general idea would apply without it as dragonchild pointed out. I found the points made in this thread by Corion and davido to be true, particularly the separation of concerns and the testing. If you carefully design a simple API for each package and stick to it you have far less "package-management to ... existing files" and no need to "doublecheck all the places I've invoked those functions". You may need a couple of runs around the block before you get the 'model' right but I think it is worth it.	[reply]


Perl Monk, Perl Meditation
	PerlMonks