More 6PAN musings: local namespaces

Front page | perl.perl6.language | Postings from June 2002

More 6PAN musings: local namespaces

Thread Next

From:

John Siracusa

Date:

June 15, 2002 19:38

Subject:

More 6PAN musings: local namespaces

Message ID:

B93171C4.3D2D5%siracusa@mindspring.com

Once nice thing about Java is the class naming convention that lets
individual companies (or even individuals, I guess) do custom development
that they can safely integrate with the "standard" Java classes and the work
of other companies/individuals without fear of namespace clashes.  For
example, the Acme Corporation can build a huge library of Java code under
the com.acme.* namespace: com.acme.widget, com.acme.widget.control, etc.
Acme can do this knowing that their stuff will never conflict with the
(hypothetical) widget classes in the official Sun JDK, or even widget
classes from other companies that make widgets (e.g. com.ibm.widget.*)

In the world of Perl 5, things are not nearly as nice.  The only convention
I recall reading about suggests putting custom code under the Local::*
namespace.  I've personally never seen anyone use that convention, but even
if it was in widespread use, namespace conflicts would still be likely when
integrating custom modules from multiple sources unless there are also
conventions for further subdivision (e.g. Local::Com::Acme::*)  AFAIK, such
conventions do not exist (...and I'm going to look really dumb in the rest
of this post if they do! :)

The result is that "vendor-specific" modules stake out any namespace they
want.  Some use company name abbreviations (IBM::*), some spell it out
(Acme::*), and some just sit right up at the top of the namespace
(Widgets::*).  More than once, I've seen such custom code (unknowingly)
collide with CPAN modules after the fact.  Combining multiple collections of
custom (i.e. non-CPAN) modules is even more problematic.

Now, I don't particularly like the Java convention of com.acme.*, but it
does have the advantage of being relatively clear to the reader.  And its
ties to the domain name system may even make for slightly easier conflict
resolution.  But it's probably not every Perlish...

Nevertheless, I'd like to see some solution to this problem for 6PAN and all
Perl 6 modules going forward.  Maybe we decided that all 6PAN modules sit
"out front" in the namespace.  So a 6PAN widget module would get Widget::*.
And then maybe we dedicate a subtree of the namespace to custom code and
define a convention for naming.  If Com::Acme::* or Local::Acme::* is too
much, then maybe X::Acme::* or something.

Another choice is to deeply nest everything, and then provide a way to
reference modules with some part of the (possibly annoying) prefix implied.
So maybe the 6PAN widget modules would really be Com::CPAN::Widget,
Com::CPAN::Widget::Control, etc., but with some syntactic sugar, it'd look
like:

    mumble Com::CPAN::*;

    use Widget;
    use Widget::Control;

or whatever.  The syntax isn't a big deal, but the namespace isolation is,
IMO.  I'm sure everyone reading this has written their own modules that were
client-specific and not suitable for uploading to CPAN.  And I'll bet
they've all used slightly different techniques for trying to isolate their
custom modules from CPAN modules, and from the rest of the world of custom
code.  Surely I'm not the only one who's been burned by the failure of this
ad hoc system?

Like I said in my last "6PAN fretting" post, maybe this has all been thought
about before.  But I thought I'd throw it out there, just in case :)

-John

Thread Next