[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