[pmc_object_design_meeting_notes] Properties
Leopold Toetsch
[ 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
Allison Randal
>
> Properties are never inherited, they belong to just that one PMC.
Well, yeah. That's what they're designed to do. But agreed that for the
sake of clarity attributes and properties should keep two separate names.
> 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.
Efficient, possibly. More stable, robust, and safe for concurrency I'm
not so sure about.
> 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.
Will this not be alleviated by the new variable-sized PMCs you're
prototyping? Anyway, I can't see that allocating storage for a single
reference to another data structure is going to break the bank.
Allison
Chromatic
> Will this not be alleviated by the new variable-sized PMCs you're
> prototyping? Anyway, I can't see that allocating storage for a single
> reference to another data structure is going to break the bank.
Seems like you'd always pay for having the data member available in the PMC
struct. Otherwise, you could copy everything to a new struct with a new PMC
member, but that's also painful.
The only time I've ever used properties in PIR was to mark an object
initializer, but we have better ways to handle that now too. I don't object
to having them, but I do think we ought to have at least one good use case to
help decide what they need to do and how to do them. Right now, I can't
think of one.
-- c
Allison Randal
>
> The only time I've ever used properties in PIR was to mark an object
> initializer, but we have better ways to handle that now too. I don't object
> to having them, but I do think we ought to have at least one good use case to
> help decide what they need to do and how to do them. Right now, I can't
> think of one.
Quick, cheap singletons are one. You're thinking of direct HLL use, when
the advantage is in giving us an implementation trick to satisfy an
abstraction in a simpler way.
I suspect, though, that the architecture of properties is closely tied
in with the architecture of roles, so let's table the properties
discussion until next week.
Allison