On Thu, 15 Jan 2004 23:00:53 -0800, Jeff Clites wrote:I think we shouldn't try to do any sort of cross-language unification.
That is, if we some day have a Parrot version of Java, and in Perl6 code I
want to reference a global created inside of some Java class I've loaded
in, it would be clearer to just reference this as
"java.lang.String.CASE_INSENSITIVE_ORDER", even inside of Perl6 code--
rather than having to do something like
"java::lang::String::CASE_INSENSITIVE_ORDER". Parrot itself would be
completely ignorant of any concept of a separator character--these would
just be uninterpreted strings, and "foo::bar" and "foo.bar" would be
separate namespaces, whatever the language.
What about languages which have the same separator, such as '::' (perl5,
perl6, ruby) or '.' (java, python)? They are going to be unified either way.
Not necessarily. Each language has a choice, at compile-time, of what separator to pass to the parrot API. For instance, even though I type "Foo::Bar" in my perl5 code, it's possible that the perl5 compiler passes "Foo+++Bar" on to parrot. So each language, via its compiler, has a choice of what it wants to do: unify, explicitly avoid unification, or not care. My point is that parrot shouldn't force the unification, but rather let each language choose its policy.
I think it's confusing to try to unify namespaces across languages, and
doesn't buy us anything.
Without namespace unification, how else are you going to even specify File::Spec from java
import java.lang.reflect.*; Class.forName("File::Spec");
, or java.lang.string from perl5?
bless $ref, "java.lang.String";
We can obviously invent suitable syntax for perl6, so that it can cope with arbitrarily named packages, but we don't have that luxury with most of the other languages we want to support.
I believe that most languages will have similar reflection API; if not, we can add such API--languages which didn't previously have all of the features which parrot provides either don't get all of those features, or will need to take advantage of them via new API.
Then the question becomes, "What about namespace clashes?", which Tim has
already addressed.
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.)
JEff
