chromatic wrote:
Properties:
I don't remember what problem these try to solve. It's difficult to discuss
one way or the other without an example.
They're solving the problem of allowing attribute-like information to be
attached to an object at runtime. In Perl 5, objects are blessed hashes
and you can add a new hash key to the hash at anytime. This is a useful
dynamic feature, but it also has disadvantages: it violates the notion
of an opaque object, you can't separate the true attributes defined as
part of the class from information added at runtime. Properties are a
way of gaining the beneficial aspects of runtime annotation, while still
preserving opacity.
STATIC_SELF:
It has an ugly name so as not to tempt people to use it. My understanding is
that the best use of this is in accessor methods, where you know it's okay to
violate encapsulation because the only way you could get to the method is if
someone did not override it.
I'm fine with an ugly name, just make it a name that clearly identifies
what it does. Dispatching vs. non-dispatching is the key defining
feature here.
Composition:
Jonathan suggested meeting on IRC next week after #parrotsketch. It's fine
with me.
Yes, sounds good.
VTABLE split:
It seems that this may depend on the ideas of the former.
Indeed.
Alison
