[CC'd to [EMAIL PROTECTED]]

On Tue, Jun 25, 2002 at 03:22:08AM -0700, Ask Bjoern Hansen wrote:
> On Thu, 20 Jun 2002, Doug MacEachern wrote:
> 
> > >    Apache::PostConfig::Whatever
> > > instead of:
> > >    Apache::PostConfigWhatever
> >
> > that's up to you for your examples.  but i personally won't be changing to
> > that convention.  true facts that another level of namespace eat more
> > memory and take longer to lookup, personally, i find it ugly.
> > also, the more structures in memory the longer it will take for
> > perl_clone() to run. both modperl use that as does threads.pm.
> > so the argument of "memory is cheap" doesn't fly as well with threads.
> >
> > perhaps asking [EMAIL PROTECTED] why the module list says:
> > "Please avoid using more than one level of nesting for module names
> > (packages or classes within modules can, of course, use any number)."
> >
> > would shed more light.
> 
> I thought it was just because Tim (I think it was; cc'ed) likes it
> better that way. =)  Maybe there's a more technical explanation.
> Tim?

Not "a more technical explanation". Naming things is far from a
science (those who've spent N years learning to be a librarian
might like to think it is).

People like to categorize or group things but are actually pretty
poor at it.  They tend to focus on one aspect of what they're naming.
Not seeing that others may be more relevant to other people or may
become more relevant over time.
 
Even with two-level names there's the classic XML::RPC vs RPC::XML
problem.
 
Multi-level names tend to make the problem worse because they include
a greater proportion of "categorization" and less of "naming".

        Cat1::Cat2::Cat3::ShortName
        Cat1::LongerName

There are probably other reasons as well but this is the one that
comes to mind.

There are two main exceptions to the above...

The first is 'frameworks' were a group of inter-related modules has it's
own top level name. Below that name it can have whatever depth of
structure it likes. Examples include POE::, and Server::.

The second is where there's a top-level name that's very generic
and is used by a large number of modules. Examples include Win32::,
Apache::, Net::, and XML::.  In these cases the "Please avoid using
more than one level of nesting for module names" guideline applies
after ignoring the top-level name.

Thus, in the case of Apache::* modules, aiming for Apache::Foo::Bar
is good. Of course, picking the right "Foo" and "Bar" is the tricky part :)
 
> The tricky and important part is to describe what
> the module does; not when it runs.
 
 ... and not how it does it.

Tim.

Reply via email to