At 11:57 AM 12/11/2003 -0500, Dan Sugalski wrote:That does, though, argue that we need to revisit the global access opcodes. If we're going hierarchic, and we want to separate out the name from the namespace, that would seem to argue that we'd want it to look like:
find_global P1, ['global', 'namespace', 'hierarchy'], "thingname"
That is, split the namespace path from the name of the thing, and make the namespace path a multidimensional key.
Or I suppose we could just punt and toss the special global access entirely and make the global namespace a hash 'o hashes hanging off the interpreter and access it like any other variable, but that makes local obscuration of the namespace somewhat difficult and I'd rather not for right now.
This'd be the time to weigh in on it, folks...
I expect we need multiple options and let compiler writers figure out which ones
they need. (see **)
Well... I was hoping for a single option, so that everyone interoperates properly. I *know* that folks writing perl programs are going to want to stick methods into the ruby and python packages that they import. (And the feeling, I expect, is mutual :)
It won't be optimal for everyone, but the needs of the dynamic languages are pretty similar so if we can satisfy them without being particularly onerous to the rest of the languages (most of whom won't make much use of namespaces at runtime anyway) I'll be happy.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
