Dan Sugalski <[EMAIL PROTECTED]> wrote: > Okay, here's a quick scoop and status.
> *) I'd like to shoot for a Feb 14th release. Names wanted. (I'm > partial to the bleeding heart release, but not that partial) I had planned towards Feb 29th. A nice dated too this year. > *) Namespaces are going to use the: > find_global Px, [key; key; key], final_name_string > format. I may add in a dummy: > find_global Px, Pn[key], final_name > in the mean time just to make things work out. Pn will get ignored. > If you have the key and leave out the element, it returns a PMC that > represents that piece of the namespace. Yes, I know there are > objections, but it's a matter of taste and space savings. We'll cope. I'd add some syntax additions and some notes: - Pn above is a NameSpace PMC, derived from Hash - an interpreter has a current namespace - located in the context, so that its restored after sub calls getinterp P2 find_global Pn, P2["."] # get current NS find_global Pz, P2[".."] # get parent NS set Pz, Pn[".."] # same find_global Py, P2["/"] # get root of namespaces find_global Px, Pn["Foo"; "Bar"] # NS of Module Foo::Bar find_global Pv, Pn["Foo"; "Bar"], "baz" # $Foo::Bar::baz var find_global Pv, Pn["Foo"; "Bar"; "baz" ] # same set P2["."], Px # switch current NS to Foo::Bar find_global Pv, Pn["/"; "java"; "some"; "glob" ] # /java.some.glob > *) Just constant keys for names right now. We'll work on dynamic keys > later, if we don't already have 'em in. Dynamic keys are (still) working ;) > *) I like Tim's namespace idea (prepending the language) and we'll > put that in, though probably for the next release. That's not really difficult, if the namespace PMC handles above directory-like traversal keys. leo
