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