Improving inspect on class objects

[Allison Randal]

Jonathan Worthington wrote:
> Patrick R. Michaud wrote:
> 
>> Lastly, there's also the issue that the cloning makes inspection
>> of classes' attributes and methods into a much more expensive 
>> operation, and helps to explain why P6object, PCT, and Rakudo
>> were generating far more hashes than I expected.

What are you using 'inspect' for? It should be rarely used (i.e. it's 
intended for advanced debugging, not for highly-optimized ordinary 
program operation).

If 'inspect' is the only way to get at some piece of data you use 
frequently, we likely need to give you a simpler way of accessing it.

>> Here's where I need a Parrot architect decision:
>>
>> I don't know how important it is that the original hashes in
>> the class object be protected from modification.  
> To me that is important. However, to me the deep cloning is also a bug...
> 
>> If we really need to protect the hashes in the class object,
>> but can allow modification of the things they address, then
>> the next-best-answer is to perform a shallow-copy clone of the
>> hashes instead of a deep-copy clone.  This would permit the
>> attribute metadata modifications I was trying to do earlier
>> and avoiding the unintended cloning of methods.  I can also
>> make this change easily.
>> 
>> I have a pressing need for a solution to this -- as things stand
>> now it looks as though Rakudo and PCT will need to maintain
>> their own copies of this information because we can't easily
>> make use of Parrot's introspection.
>>   
> Changing deep to shallow copying is, from my angle, a bug fix as much as 
> anything else (as in, if you'd suggested just that change on IRC, I 
> mighta JFDI). (And yes, it could change program behaviour somewhere, if 
> folks were relying on it deep-cloning rather than shallow-cloning. But I 
> find that quite unlikely.)

I'm not entirely opposed to changing the deep-cloning to shallow 
cloning, though we should be very careful about opening up any holes in 
class encapsulation (people will abuse it, guaranteed). We should 
certainly have custom cloning for class introspection so the actual 
method objects are returned, instead of cloned copies of the method objects.

But, 'inspect' is definitely not the preferred way of modifying class 
attributes. If you use 'inspect' this way I guarantee we'll break it 
later when Parrot gets better at enforcing read-only access (assuming we 
ever make it possible in the first place). The 'inspect' vtable function 
is exactly that, *examining* the guts of the class/object, not modifying 
them.

The right way to add custom attribute metadata is through the 
'add_attribute' vtable function. If you look at: 
docs/pdds/pdd15_object_metamodel.png you'll see it was originally 
designed to allow user-defined metadata flags in the attribute metadata.

In the vtable signature for 'add_attribute', 'type' should actually be 
'metadata' which can alternatively be a hash of metadata for the 
attribute, rather than just type:

   VTABLE void add_attribute(STRING *name, PMC *type) {


This doesn't allow for modification of metadata for an existing 
attribute. I'm open to adding 'get_attr_*' and 'set_attr_*' vtable 
functions to the Class PMC for modifying attribute metadata. It's 
sensible that the 'getattribute' and 'setattribute' opcodes on a Class 
work with attribute metadata, while on an Object they work with 
attribute instance data.

Allison