On 6/16/02 1:50 AM, Luke Palmer wrote:
> On Sun, 16 Jun 2002, Michael G Schwern wrote:
>> Let's dump out the sack of namespace partitioning problems:
>> 
>> What if Acme decides it wants to release part of it's code as Open Source?
>> (Happens a lot).  Does it release it as Com::Acme::Text::Thing or
>> Text::Thing?  If the name changes, do they have to rewrite all their
>> existing code?  Or maybe maintain two names?
>> 
>> What if Acme changes it's name?  Do they stay as Com::Acme or change all
>> their code?  I've experienced something similar to this at a company which
>> was bought and the subsequent s/Old Name/New Name/ in all the copyrights and
>> licenses in all the code.
>> 
>> What if Acme Corp. and Acme Widgets Inc. both decide they want to use
>> Com::Acme?  What happens if lawyers get involved?
>> 
>> What if Acme Corp. decides it wants to enforce it's trademark on Com::Acme?
> 
> You can't get it perfect, realistically.  There could always be two
> parties that want to call their module some name. [...]
> 
> I'm okay with the current setup personally, as far as naming goes.

Spoken like someone who hasn't had most of the above happen to them :)  I've
had the first two happen to me multiple times already!  As for the second
two, those will probably come up not matter what system is chosen.  But
surely we can solve the first two (which are much more common, in my
experience.)

> I'd like there maybe to be a more formal classification, say CHS (CPAN
> Heirarchy Standard).  I like it, though, because it's fairly intuitive on my
> use lines.  We haven't had very many collisions thus far. And if they start,
> that will just force people to be more creative with their naming.

Well, define "haven't had very many collisions."  I've certainly never
"reported" mine, but that doesn't mean I haven't had them and been
frustrated by them!  And even the stuff that's already in CPAN is kind of a
mess, hierarchy-wise.

For example, is HTML::Mason really primarily an "HTML" thing?  And just look
at the various OS-specific modules.  The poor Mac:: modules are just sitting
out there hoping their top-level prefix doesn't get taken over by some
as-yet-unknown (but soon to be super-popular) protocol or product.  And look
what happened when Mac OS X came along.  We get MacOSX:: at the top level
too.  Where's MacOS:: then?  And does anyone really think LWP:: is a good
top-level name?  With a good, standardized hierarchy, people could call
their modules by whatever fanciful "product names" they want, provided the
"LWP"-ish part is prefixed by something more conventional.

> And about the local thing, if they don't use (no pun intended) the Local::
> heirarchy for local things and their code collides and breaks, that's
> their problem.  Module naming can't be smart for us, we need to help out.

But what if they use Local:: and then want to use someone else's Local::
modules?  (Say they purchased another company or are partnering with
someone.)  What if they want to release their code to CPAN, despite the fact
that it may still be vendor-specific?  (e.g. a parser for Acme's electronic
widget order receipt or something.)  I think there are real problems to be
solved here.

-John

Reply via email to