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
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 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 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
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/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
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
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.