Allison Randal wrote:
Jonathan Worthington wrote:
I implemented this to test it out and it kinda worked. However,
properties don't get serialized so if you compile the program to a
PBC and run that it doesn't work.
Why don't they get serialized?
I guess, that's just not implemented. But I don't know if this is a
quirk of the implementation or a design decision that properties are
just runtime things. If we want it to always happen, it needs to be
implemented as part of the standard PMC packing code though, I think.
(Note that default.pmc implements properties, so any PMC can have them
set, it appears; serializing them as standard would thus make sense).
Additionally, properties don't get inherited.
In the sense that they're only attached to individual object instances
of the class, not to the class itself. And even if they were attached
to the class, it would be to the class PMC, and wouldn't be picked up
by subclass PMCs.
Although, in this case what we're talking about is a property attached
to an object instance of the namespace class. Inheritance is
determined by the classes associated with the namespace object, not
the namespace object itself. The storage of vtable methods in the
namespace is really only temporary until they can be loaded as vtable
overloads on the class. (It's also there for the sake of later use by
other classes if they become associated with that namespace.) The
vtable overloads only enter into inheritance once they are loaded into
the vtable.
This is why properties seemed like a good fit: the vtable entries in
namespaces are optional, out-of-band information, only used in
loading. But, they could just as well be implemented as a separate
attribute in the namespace class.
Agree; looking now at what I had to do (walk the MRO) to get inheritance
of :vtable methods to work already, doing it with the data in properties
is no harder. That leaves the serialization issue as the main one. A
ruling on that, and I can implement :vtable using a property. (leo
pointed out the double indirection, as you're looking up the vtable hash
in the property hash, is a performance issue - we can perhaps optimize
this later...I care more about getting the correct behavior right now).
It'd be nice to actually attach these methods to a v-table itself
somehow. However, unless we make classes a compile-time construct
rather than "turning a namespace into a class" using newclass as we
do now, I don't see how this can happen (at least, not cleanly).
It also wouldn't allow for runtime association of an anonymous class
with a namespace, or runtime switching of the namespace a class is
associated with.
Must...get...head...out...of....static-language-world. :-)
Thanks,
Jonathan
