On Tue, Sep 07, 2004 at 09:26:14AM -0400, Dan Sugalski wrote: > Time to nail this. > > We need namespaces. Duh. We talked about this in the past.
I've reordered these to put the simple/fundamental things first: > *) Namespaces are hierarchical > *) The top-level namespace ["__INTERNAL"] is taken. > *) Each language has its own private second-level namespace. > *) Parrot's base library goes into ["_INTERNAL"; "Parrot"] I presume you've looked at this thread again: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=20040116110746.GA38383%40dansat.data-plan.com Anything you disagree with there? I think a filesystem analogy is a very helpful one. Many of the issues are similar and there's a lot of experience with how to address them in creative ways. I'd suggest adding: *) Each interpreter has a "current root namespace" from which namespace searches start. (Analogous to chroot() in unix.) Apart from enabling functionality analogous to chroot() in unix, it also avoids having to prepend ["_INTERNAL"; "<language>"] to all namespace lookups and avoids the overhead of then traversing through those two levels. *) ...something here about namespace objects and how namespace traversal is performed (methods/vtable foo)... > *) Namespaces and sub-spaces can be overlaid or aliased > > So code can, for example, throw a layer over the ['foo'; 'bar'; > 'baz'] part of the namespace that gets looked at first when searching > for something. These layers can be scoped and shifted in and out, > which means its possible to have two or more ["IO"] namespaces that > have completely (or partially) different contents depending on which > space is in use. I'd be interest to know your thoughts on how that that might be implemented. Seems like you'd need a 'sparse tree' of proxy namespace objects that you'd start searching first and that would fallback to the corresponding real namespace object at the point no match was found. But it doesn't seem worthwhile going into much detail till the "namespace traversal" bullet above is filled out. (I'm reminded of the translucent filesystem (TFS), but it's effect is globally visible.) > It's also possible to hoist a sub-space up a few levels, so that the > ["IO"] space and the ["__INTERNAL"; "Perl5", "IO"] namespace are the > same thing Not actually "move", but "make visible at"? Like a symbolic or hardlink in a filesystem. Tim.
