Gordon Henriksen <[EMAIL PROTECTED]> wrote: > Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> What about: >> >> getinterp P2 >> set P1, P2['global';'namespace';'hierarchy';'thingname'] > What if global.namespace happens to be autoloaded or otherwise magic? > Will the get_keyed break down and do something equivalent to this? > getinterp P2 > set P1, P2['global';'namespace'] > set P1, P1['hierarchy';'thingname'] > Meaning the construction of an extra multikey? Yech, maybe. That's absolutely the same. Multikeys work on the nested aggregates, at least if you are considering current PerlHash implementation. But - AFAIK - nothing was said yet, how the namespace hierarchy is done internally. It could be a HoHoH or a concatenated string key of an one level flat hash - the value being the symbol name. >> Constructing a multy-key by hand isn't that simple (or would need >> hacking imcc) (and Key componenent separator is a semicolon). > -> The nameless root namespace is an easy-to-get-to parrot or > interpreter global, so there's no need to have a separate interface > to access the global namespace vs. accessing a namespace in a PMC > register. set P1, P2["the_global"] # P2 is still the interpreter So there is no special case. > (Though interp-is-a-namespace is cute. Maybe too cute, if namespaces > are subclassable.) Different interpreters (threads), different global namespaces ... > -> Namespaces have methods/ops to look up a contained symbol (just > one level), where any string is a valid symbol. (And there's the > option of not recursing into parent namespaces; i.e., looking only > at "declared" members.) Considering Melvins f'up and that, it might be better, to move that functionality into a NameSpace PMC. That can be overridden and still does the right thing for the standard case. > -> Namespaces also have methods to traverse a path of symbols That seconds above statement a lot. > get_globals Py Ah the get me a namespace PMC - yep. leo
