Ovid wrote:
----- Original Message ----
From: Nik Clayton <[EMAIL PROTECTED]>
Ovid wrote:
I'm perfectly comfortable with this idea, but what I'm trying to figure
> > out then, is the namespace for my parser. It's a TAP parser, after all.
> > Any suggestions? I see that Adam has suggested a TAPx:: namespace,
> > but there could still be competing TAPx::Parser modules. Don't know if
> > that would bug folks, though.
TAPx::<CPANID>::Parser
Thought about that, but immediately discarded it. TAPx::OVID::Parser
> doesn't say anything about the parser other than authorship and the
> latter is verified by glancing at the docs. My jumping on the
> TAPx::Parser namespace is almost as bad as my taking TAP::Parser, so
> I'm just trying to figure out how to truly distinguish my (currently
> parser from others. I suspect it will be as arbitrary as your idea,
though :)
The problem with that is that we risk ending up with a proliferation of
modules with odd names just to avoid namespace clashes. See all the
modules on CPAN with ::Simple or ::Lite suffixes, or the Email::/Mail::
split. And then there's Schwern's original example, CGI.pm.
At least CPAN IDs are globally distinct. Two authors that want to write
a simpler parser can't clash over who gets to own TAP::Parser::Simple
this way.
It may be unwieldy, but this is something that Java managed to solve
with 'reverse domain' syntax for class hierarchies.
N
