Improving inspect on class objects

[Jonathan Worthington]

My couple of cents...

Patrick R. Michaud wrote:
> Short version:  Can we change attribute and method inspection for
> class objects to return the _class->attrib_metadata and 
> _class->methods hashes directly, instead of cloning the hashes 
> (as it does now)?
>   
I'd rather not do just that, but...

> I suspect the cloning is intended to prevent introspection from being
> used to modify the hashes held in the class object, 
It is, and I think that we should continue to protect against this. 
People thinking they can add attributes and methods that way will likely 
lead to various subtle bugs.

> but the cloning here has some unfortunate side-effects.
>
> (Note that cloning a Hash PMC in Parrot currently has "deep cloning" 
> behavior -- the values in a cloned hash are clones of (not references to) the values in the original.)
>
>   
IIRC, I wrote the code in question here. I suspect I must have 
overlooked or just not known about this (it's bitten me recently 
elsewhere, so I know now). My original intention was a shallow clone, 
not a deep one.

> 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.
>   
If we're cloning all of the attribute hashes and the Sub PMCs then yes, 
that is going to be rather costly.

> 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.
>
>   
...and for now this is my preferred solution.

> If we need something more radical than either of these, then we
> need the architect to specify what it should be.
>
>   
I think in the long run a way to return a read-only thing but upgrade it 
to rw when we need to do modifications to it (which the Class PMC would 
do) would be a nice optimization, but the shallow copying wins us quite 
a bit on that now, and I think fixes all of your issues without making a 
particularly radical change.

> 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.)

Hope this helps,

Jonathan