[VPM] Re: RFC: multi-package module best practices

Darren Duncan darren at DarrenDuncan.net
Fri Mar 5 18:17:59 CST 2004


Thanks for your reply, Perrin.

At 4:29 PM -0500 3/5/04, Perrin Harkins (perrin at elem.com) wrote:
>[] and in fact I am more scared when I see one big honking module file.

In this case, each of the two components and their sums is small 
and/or medium-small with one piece being majority.

Here is how the totals break down.  The numbers include all code, 
whether methods or constant declarations, and code comments, but not 
POD.  "total" is everything in the module, "shared" is common 
utilities or constant data, and the capitalized items are methods 
specific to the component package.

Locale::KeyedText
	- total - 6K
	- shared - 1K
	- Message - 2K
	- Translator - 3K

SQL::SyntaxModel
	- total - 72K
	- shared - 37K
	- Node - 31K
	- Container - 4K

Rosetta (this is incomplete but stands to grow about 50% larger)
	- total - 25K
	- shared - 6K
	- Interface - 17K (main growth to be here)
	- Engine - 2K

Suffice it to say, none of these look near a "big honking" size. 
(Certainly not like some multi-megabyte modules out there.)

Perrin said:
>I don't buy it.  The majority of popular distributions contain more than
>one module.  This doesn't seem to be scaring anyone, [...] Splitting 
>your code up into manageable chunks is a good thing, and defining 
>multiple
>packages in one file is very rarely a good idea.

Despite what I said before, I can concede that some of my modules may 
indeed be better to split up into 3 pieces each.

However, I only see that working with Locale::KeyedText and Rosetta. 
I do not see a split working so well with SQL::SyntaxModel.

(I see it as somewhat ironic that it is the smallest modules of the 
modules that are easiest to find rationales for splitting.)

Any further suggestions or comments?

Thank you. -- Darren Duncan



More information about the Victoria-pm mailing list