We already have find_global and store_global. These work fine, we're going to keep them, though I think we're going to pare down the semantics a bit.
What I want to keep is:
$Px = find_global 'name' $Px = find_global [key; key; key], 'name'
store_global 'name', $Px store_global [key; key; key], $Px
These load and store from the current namespace and the specified namespace respectively. The case where the namespace is specified by string I think should go away. (And this'll impact me quite a bit, but it's still the right thing to do)
Next I want to add in the op variants:
$Px = find_global [key; key] $Px = find_global $Px, [key; key] $Px = find_global $Py, 'name'
to fetch out namespace PMCs and work with fetched namespace PMCs. That is, if I have the namespace Foo, Foo::Bar, and Foo::Bar::Baz, and then have a thing named xyzzy in Foo::Bar::Baz, I can get it by doing:
$P1 = find_global ['Foo'; 'Bar'; 'Baz'], 'xyzzy'
or
$P0 = find_global ['Foo'] $P1 = find_global $P0, ['Bar'; 'Baz'] $P2 = find_global $P1, 'xyzzy'
or
$P0 = find_global ['Foo'; 'Bar'; 'Baz'] $P1 = find_global $P0, 'xyzzy'
That is, if we don't specify the name of the thing in the namespace we get the namespace PMC itself, which we can then go look things up in. This is handy since it means code can cache the namespace PMC so if there are a dozen variables to go fetch out, we don't have to do the multi-level hash lookup each time. (That'd be nasty)
Making one section of a namespace an alias for another part is just a matter of getting the PMC for the section of the namespace tree you want to alias and sticking it into the namespace it should hang off of. Right *now* I'm not inclined to have a store_global variant to do this, but if we want to completely hide all namespace operations behind ops I'm OK with that.
Now, with that out of the way, let's talk about overlaid namespaces.
The namespace specification has always allowed for multiple overlapping namespaces. What this is supposed to allow you do to is have two or more full namespace trees available at once, with lookups and stores automatically running through each of the namespaces until the appropriate thing is found. (And the fact that we want to do this, and do it sorta-kinda lexically, is a reason for the namespace ops)
For this, we're going to add the ops:
overlay_namespace $Px
overlay_namespace $Px, $Iy remove_namespace $Px
remove_namespace $IxThe first two add the namespace $Px to the current search list -- the first version makes it the first space that will be searched, the second form puts it at $Ix in the list of namespaces to search.
The remove ops removes a namespace from the list. The first version removes the namespace $Px (the same PMC you used to add in with overlay_namespace) from the search list wherever it is, the second form removes the namespace at offset $Ix.
Right now (and I expect this will change, but we're starting simple) store_global will *always* store into the first namespace in the list, while load_global will look through the namespaces in the list until it finds one that has the thing being looked for, doing the error pitching only if the thing isn't in any of the namespaces in the list
So, basically, a sub doesn't have a single namespace tree -- it has a list of trees, and we search that list for each lookup, and we store into the first tree in the list on store.
Comments?
--
Dan--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
