Hi @all,
[ shortened: ]
Recommendation: Deprecate property support in PMCs.
Allison: Would it help if we call them "static attributes" and "dynamic
attributes"?
No. Attributes and properties are almost orthogonal concepts.
Properties are per PMC (or object, as that's a PMC too) add-on Hash PMCs that
store some kind of information for that very PMC. Typically a total overkill,
as in all usage I saw, just one item of information in the hash was stored.
E.g. the id in ealier TGEs.
Properties are never inherited, they belong to just that one PMC. Therefore a
much more efficient implementation of current properties is to use one
AddrRegistry hash (which is keyed by the PMCs address) and store this
information there.
E.g. 10000 PMCs with props:
10000 additional Hash PMCs with one item
with AddrRegistry:
1 Hash with 10000 items
The other nasty "feature" of properties is: as they *might sometimes* be used
at runtime with any PMC, we still have to provide some storage place for the
property for *all* the innocent other PMCs, which don't never ever use
properties. This is a serious drawback for a good PMC and interpreter design.
Attributes are different.
A runtime attribute would still be inherited by a subclass, if the subclass is
created thereafter, but that might depend on the object model. If some object
model, like Perl6' needs it, it can easily reserve an extra attribute slot
for gathering runtime attributes in an addon hash. This is according to
audreyt at the last hackathon at my place re object model.
Perl 6 'properties' are anon subclasses and have nothing in common with
current parrot properties.
Or IOW (best summarized by chromatic) "I don't remember what problem these try
to solve."
Thanks,
leo
