Re: More 6PAN musings: local namespaces
[EMAIL PROTECTED] (Damian Conway) writes: Larry has previously mentioned the prospect of Perl 6 module names being extended to include version number and author. Yes, we even talked about it extensively at the CPAN meeting in Monterey 2 years ago. =) -- ask bjoern hansen, http://askbjoernhansen.com/ !try; do();
Re: More 6PAN musings: local namespaces
On Tue, Jun 18, 2002 at 05:32:40PM -0700, Larry Wall wrote: I expect to end up with a multi-level system, where you can use anything from a DNS name (guaranteed to contain dots) through author IDs (no dots) to blessed top-level names for universally acclaimed modules, for some definition of universal. Plus the technological fix of aliasing, as several of you have discussed. Basically, we name interfaces at a more abstract level than we do implementations. Devil in the details, as usual... Sounds good. Just try to not have it turn into X.400 addressing and we'll be fine (or was that X.500... which one was the funky LDAP-like ugly-as-sin thing the Europeans (i.e. ISO) tried to pretend was better than Internet-style addressing because it allowed you to route mail based on how much fiber the recipient had in their diet?) -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF We just say, `it's on the computer, and it's because we're on the hellmouth,' and just get away with it, but that doesn't make us bad. -Joss Whedon
Re: More 6PAN musings: local namespaces
Larry has previously mentioned the prospect of Perl 6 module names being extended to include version number and author. If this were to be done, would seem reasonable for the author component to simply be the author's CPAN username. These are guaranteed unique, are frequently mnemonic, are necessary prerequisites for putting a module on the CPAN in any case, and also map straight onto email addresses through which authors can be contacted. Damian
Re: More 6PAN musings: local namespaces
Larry has previously mentioned the prospect of Perl 6 module names being extended to include version number and author. If this were to be done, would seem reasonable for the author component to simply be the author's CPAN username. These are guaranteed unique, are frequently mnemonic, are necessary prerequisites for putting a module on the CPAN in any case, and also map straight onto email addresses through which authors can be contacted. Damian
Re: More 6PAN musings: local namespaces
On 6/18/02 6:10 PM, Damian Conway wrote: Larry has previously mentioned the prospect of Perl 6 module names being extended to include version number and author. If this were to be done, would seem reasonable for the author component to simply be the author's CPAN username. These are guaranteed unique, are frequently mnemonic, are necessary prerequisites for putting a module on the CPAN in any case, and also map straight onto email addresses through which authors can be contacted. That's fine for what it is, but I don't think it has the right granularity for the problem I described in my original post. If Acme wants to create custom Acme modules in-house and ensure that they will play well with modules from anyplace else, they can't very well rely on a CPAN author name to isolate their namespace. So they're back to making up their own convention under Local:: (and risking conflicts with other companies that try to do the same), or using Acme:: (whoops! CPAN conflict!), etc. -John
Re: More 6PAN musings: local namespaces
On Tue, 18 Jun 2002, John Siracusa wrote: : On 6/18/02 6:10 PM, Damian Conway wrote: : Larry has previously mentioned the prospect of Perl 6 module names being : extended to include version number and author. : : If this were to be done, would seem reasonable for the author component to : simply be the author's CPAN username. These are guaranteed unique, are : frequently mnemonic, are necessary prerequisites for putting a module on the : CPAN in any case, and also map straight onto email addresses through which : authors can be contacted. : : That's fine for what it is, but I don't think it has the right granularity : for the problem I described in my original post. If Acme wants to create : custom Acme modules in-house and ensure that they will play well with : modules from anyplace else, they can't very well rely on a CPAN author name : to isolate their namespace. So they're back to making up their own : convention under Local:: (and risking conflicts with other companies that : try to do the same), or using Acme:: (whoops! CPAN conflict!), etc. I expect to end up with a multi-level system, where you can use anything from a DNS name (guaranteed to contain dots) through author IDs (no dots) to blessed top-level names for universally acclaimed modules, for some definition of universal. Plus the technological fix of aliasing, as several of you have discussed. Basically, we name interfaces at a more abstract level than we do implementations. Devil in the details, as usual... Larry
Re: More 6PAN musings: local namespaces
On 6/18/02 8:32 PM, Larry Wall wrote: I expect to end up with a multi-level system, where you can use anything from a DNS name (guaranteed to contain dots) through author IDs (no dots) to blessed top-level names for universally acclaimed modules, for some definition of universal. I'm not sure understood all of that, but it sounds interesting :) Plus the technological fix of aliasing, as several of you have discussed. Basically, we name interfaces at a more abstract level than we do implementations. Devil in the details, as usual... I eagerly await those details... ;) -John
Re: More 6PAN musings: local namespaces
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
More 6PAN musings: local namespaces
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
Re: More 6PAN musings: local namespaces
On Sat, Jun 15, 2002 at 10:35:48PM -0400, John Siracusa wrote: 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. 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? A variation on the last two already happened. Could someone who knows the full story relate what happened when Sun wanted to release it's core Solaris perl modules to CPAN? I know it involved trademarks and guaranteeing a namespace exclusively for Sun. It would be nice to have someone experienced with Java to relate how things have worked out with the com.acme.* scheme. -- This sig file temporarily out of order.
Re: More 6PAN musings: local namespaces
On Sun, 16 Jun 2002, Michael G Schwern wrote: On Sat, Jun 15, 2002 at 10:35:48PM -0400, John Siracusa wrote: 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. 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 mean, you could number modules based on the cardinal (or ordinal... I forget) number of their submission... ha ha hA HA HAAA HAAA! I'm okay with the current setup personally, as far as naming goes. 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. 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. Luke
