Improving inspect on class objects
Jonathan Worthington
jonathan at jnthn.net
Sun Jan 4 16:58:36 UTC 2009
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
More information about the parrot-dev
mailing list