Lennon Day-Reynolds wrote:
> The standard library (and other modules that follow the
> General::Specific style) also fit the model that CPAN uses, which has
> proven itself quite scalable up to thousands of packages.
> 
> I think it would be better to encourage highly-descriptive package
> names; if anything, it seems that it would be better for authors of
> packages which fit the same niche to discover the potential overlap
> sooner, rather than later, so that redundant work could be minimized.
> 
> Lennon
> 
> On Tue, 13 Jul 2004 06:28:31 +0900, Gavin Sinclair
> <gsinclair / soyabean.com.au> wrote:
> 
>>
>>On Tuesday, July 13, 2004, 1:28:40 AM, David wrote:
>>
>>
>>>Hi --
>>
>>>On Tue, 13 Jul 2004, Robert Klemme wrote:
>>
>>>>"David A. Black" <dblack / wobblini.net> schrieb im Newsbeitrag
>>>>news:Pine.LNX.4.44.0407120755490.11648-100000 / wobblini...
>>>>
>>>>>I would emulate the built-in/standard library style as much as
>>>>>possible, i.e., no company names and a General::Specific::MoreSpecific
>>>>>nest.
>>>>>
>>>>>If company names absolutely must enter into it, it would be better to
>>>>>put them at the other end; I'd rather "require
>>>>>'xml/parsers/AcmeXMLCo'" than 'AcmeXMLCo/xml/parser'.  The former is
>>>>>not ideal, but it's less disruptive and less ungainly than the latter.
>>>>
>>>>But having the company name as prefix makes installation easier, because
>>>>otherwise if your package consists of several modules you'll have to
>>>>manage several sub folders.
>>
>>>Yes, but all for the common good.  I don't see the names of Matz's
>>>company, or those of other core developers, in the standard library.
>>
>>The standard library should be considered a special case, IMO.  I'm
>>not advocating a particular naming format here, just making that
>>point.
>>
>>Gavin
>>
>>
> 
> 
> 
Good points.

But this opens up the scenario where a poor-quality module keeps a 
common-sense name simply because it was first--while a newer, perhaps 
much better library that serves the exact same purpose has to grab a 
more esoteric name.

The more appropriate the module names, the more potential for conflict 
between modules that provide similar functionality from different authors.