Improving inspect on class objects

Allison Randal allison at parrot.org
Mon Jan 5 09:09:07 UTC 2009



Patrick R. Michaud wrote:
> On Sun, Jan 04, 2009 at 05:00:46PM -0800, Allison Randal wrote:
>> 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).
> 
> Currently it's used for two purposes:
> 
> 1.  When creating a new instance of the class, it's used to identify
>     (a) the list of attributes that need initialization and 
>     (b) the metadata needed to initialize each attribute
> 
> 2.  When defining the class itself, I'm (ab)using it to modify
>     the attribute metadata, since at present there doesn't
>     appear to be another interface available for doing so.
> 
>> 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.
> 
> "List of attributes and metadata" is what we will want/need frequently,
> as identified in (1) above.

Okay, (2) is taken care of with 'get_attr_*'/'set_attr_*'. (1) works 
fine as a clone (not modifying, just reading), but creating a clone of 
the attribute metadata every time you instantiate a new object is way 
too expensive.

I suggest exploring what we need out of this a little further. Again the 
'inspect' vtable function isn't really right for it. It might be a class 
method.

>> 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) {
> 
> That would work just fine for me -- I'm guessing that the
> keys in 'type' ('metadata') would end up being used as the
> keys in attrib_metadata ?

Yes, should be. Pseudocode something like "if the PMC argument is a 
Hash, the keys become the keys in attrib_metadata" and "if the PMC 
argument is anything other than a Hash, store it as the 'type' in the 
attribute metadata".

>> 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.
> 
> This would be a very workable solution from my perspective.
> I'll be glad to make these changes to trunk if you're willing
> to commit to them.

Sounds good.

> In the 'rvar' branch I've already adjusted the inspect_str vtable 
> so that it returns a shallow clone of hashes instead of a deep clone,
> and I can merge that into trunk also.

Since we'll add 'get_attr_*' and 'set_attr_*', keep 'inspect' on 
attribute metadata and the attribute index as a deep clone (to entirely 
prevent modifying them via 'inspect').

The 'parents', 'all_parents', 'methods', 'vtable_overrides', and 'roles' 
should be shallow cloned, so you get a different array, containing the 
original class/role/method objects.

The new PMCs created for 'name','id', and 'flags' shouldn't be cloned at 
all.

Allison


More information about the parrot-dev mailing list