Jeff Clites writes: > We could certainly do some sort of language-specific prefixing, as Tim > suggested, but it seems that we are then going to trouble to unify, > only to immediately de-unify. Certainly, a random Java programmer > shouldn't have to worry about naming a class so that it doesn't > conflict with any class in any other language in the world--that's > silly, especially since this Java programmer may not even know about > parrot. (But it matters, if later someone wants to run his code on top > of parrot.) If we use per-language prefixing, then I'm certainly going > to have to be aware of what language is "hosting" a given class, and so > it seems natural to instead just use that class name as I would expect > it to be written--"java.lang.String" for Java, for example. > > And again, one of my basic points here is that although namespace > nesting could be useful for some things (maybe), it isn't what's going > on in most languages anyway. For instance, Java does not have nested > namespaces--it just happens to have a convention for namespace naming > which involves dots, and also uses a dot as the separator between a > namespace name and the variable or class name. (Though I suppose > there's really 2 separate, but related, issues--how namespace names are > represented internally, and whether these names imply namespace > nesting.)
But in fact, one of Perl 6's key features depends on heirarchical namespaces: namespace aliasing. And then if the Java programmer accidentally named a class the same a some perl module (unlikely, because you probably won't see Perl with a org::bazbar::Foo module), Perl is able to move that namespace somewhere else to make room for another conflicting module. Luke
