Jonathan Worthington wrote:
This is a good place to start, but I agree it's not what we want
ultimately. Chip and I talked about attaching a data structure of
vtable entries as a property on the namespace object.
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?
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.
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.
Maybe something to be addressed in the objects PDD.
Yes, good entry for the questions section.
Allison
