Root-relative namespace keys

[Patrick R. Michaud]

On Tue, Jan 06, 2009 at 08:44:31PM -0800, Allison Randal wrote:
> I'm going to start out by taking a step back. 

Good approach -- I like where we're going now.

> For class lookups 'newclass', 'subclass', 'get_class', and 'isa' all  
> accept a string name or a PMC. That PMC can currently be a Key, String,  
> ResizableStringArray, or NameSpace. 

First, for the record (and to perhaps get it bumped up a bit in
priority for fixing), the above opcodes do not work with 
with ResizableStringArray -- see TT #8.  

Beyond that, it would be nice if we could locate classes using _any_ 
array and not just ResizableStringArrays -- for example, in PCT we 
might easily end up with an array of String PMCs, or in Rakudo we 
might end up with a List of Str objects.  Having to convert those 
into a RSA (especially from a foreign hll) might be a pain.  However,
I'm willing to live without them if we can at least get RSA to work.

> [...stuff about using hashes to identify classes, and hashes in general]
>
> This feels flexible, it feels dynamic, and it doesn't feel hackish.  
> Thoughts, comments, variations on a theme?

What you propose sounds very workable to me, although it feels a 
bit "heavy".  I do see some places where it might be very nice to 
encode hash constants in PIR, so this approach does aim towards a 
more generally useful mechanism.  I think it's worth considering.

That said, since you've now made the change to allow the 'isa' opcode
to return false for null PMCs (r35087),  my concerns about using
namespaces to locate classes are _greatly_ lessened.  (I do now
greatly wonder why 'isa' is getting special null PMC treatment 
relative to other opcodes -- but that's a separate topic.)

So, with the change you made to 'isa' in r35087, and assuming that 
we can indeed get the class opcodes to work with arrays 
(i.e., resolve TT #8), I'm perfectly happy again with using 
get_namespace to identify classes and then all we need is a way
to handle :multi.  That's now a separate thread, and I'll respond
(positively) there.

Lastly, for the case where we're attempting to _create_ a class in a 
foreign HLL, requiring extra setup work (e.g., creating the foreign 
namespace) doesn't bother me at all.  Creating a foreign class is 
_very_ rare and really doesn't deserve any special opcode support 
beyond what we already provide (assuming the fixes above).

Given the above, I'm not pushing strongly for the additional 
"create from Hash" changes you proposed here.  I'm not at all opposed 
to the revised approach, and there are potentially some big
advantages.  However, with the other fixes in place (or hopefully
coming soon) I don't have an immediate need for this to be
resolved any further, and we can likely more usefully spend our 
energies elsewhere for now.

Pm