Currently find_global is prepared to accept a key or a namespace, and
distinguishing namespaces from arrays is starting to get just a little
too polymorphic for an opcode.
I'm thinking that between get_namespace and the untyped namespace interface,
find_global is obsolete. Where you would say
$P0 = find_global key_or_array, 'foo'
you change to
$P99 = get_namespace key_or_array
$P0 = $P99['foo']
which also incidentally encourages(!) compilers to cache namespace pointers.
--
Chip Salzenberg <ch...@pobox.com>
I'm more inclined to say find_global just shouldn't accept a namespace
PMC as an argument. I really don't want to eliminate the form that pulls
a variable from the currently selected namespace:
$P0 = find_global 'foo'
(The namespace is already "cached" for you, so it doesn't make sense to
retrieve it and cache it manually.)
And if you keep the one-argument form, it makes sense to keep the
two-argument form. (Though, there's likely a better name for it than
'find_global'. Like, 'find_symbol', or 'get_symbol'.)
Any changes to find_global should also apply to store_global, since
they're a matched pair.
Allison
Agreed. And find_global gets a bit overloaded anyway.
> you change to
>
> $P99 = get_namespace key_or_array
> $P0 = $P99['foo']
>
> which also incidentally encourages(!) compilers to cache namespace pointers.
Ooh. I like it very much!
Pm
Okay, to flesh this out as a viable alternative, Chip/Patrick we need:
a) a standard pattern for compiler writers to follow to cache namespace
PMCs (various compilers may vary the pattern, but we need one
straightforward base example)
b) a way to access a symbol in the currently selected namespace without
retrieving the namespace by its literal name (this may work out to be
part of the more general caching strategy)
Allison
For those who aren't reading the subversion logs:
1. Why aren't you? :-)
2. I've done this
--
Chip Salzenberg <ch...@pobox.com>