Re: pdd21 vs. find_global
On Sat, Jul 01, 2006 at 10:37:59PM -0500, Allison Randal wrote: > I'm more inclined to say find_global just shouldn't accept a namespace PMC > as an argument. For those who aren't reading the subversion logs: 1. Why aren't you? :-) 2. I've done this -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd21 vs. find_global
Patrick R. Michaud wrote: 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! 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
Re: pdd21 vs. find_global
On Sat, Jul 01, 2006 at 05:10:59PM -0500, Chip Salzenberg wrote: > Darn, find_global has collided with pdd21. > > 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. 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
Re: pdd21 vs. find_global
Chip Salzenberg wrote: Darn, find_global has collided with pdd21. 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. 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
pdd21 vs. find_global
Darn, find_global has collided with pdd21. 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 <[EMAIL PROTECTED]>