At 12:56 PM 8/9/2001 -0700, Nathan Wiger wrote:
>Dan Sugalski wrote:
> >
> > At 03:39 PM 8/9/2001 -0400, Kirrily Robert wrote:
> > >=head1 THINGS THAT NEED DOING
> >
> > Add to this "Define required metadata for perl modules". I think Larry
> > wants version and author as required at the very least.
> >
> > FWIW, my current view of "The Module Plan" is for all modules to be
> > identifiable via a module name/author ID/version triple.
>
>This is kinda sketchy to me. I like the module name and version, but
>author is a little weird. For CPAN modules, it should be
>straightforward: it's your CPAN id. But do we really *want* to support
>two modules with the same name but different authors?
No. In fact, we don't *want* to. On the other hand, perl does an awful lot
of stuff we don't want to do.
There's nothing stopping you from having, for example, a Foo::Bar module
from CPAN and a Foo::Bar module locally. (Nothing besides good sense, but
we all know not to rely on *that* :) Besides, you can have some module
in-house that later collides with a CPAN module because you didn't register
your local stuff (as you really shouldn't, if it's company-private) and it
uses a namespace someone else later grabs. In that case, author's a good
distinguisher. As is author if you have two competing Net::HTTP modules,
for example, written by different people.
Also don't discount the possibility that your perl code uses, say,
XML::Simple and calls Python code that uses the namespace equivalent of
XML::Simple (however you do that in Python) and thus you have a collision
that way too.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
