Object design revisions

[Allison Randal]

I just finished reviewing docs/dev/pmc_object_design_meeting_notes.pod,
which is a summary of a design discussion I asked particle to lead at
the hackathon last weekend. It's a fantastic piece of work, and nicely
organizes the ideas we've been kicking around the past few months.
Thanks to particle and everyone else who contributed.

I've added responses after each recommendation, if you have any
questions or comments pull them onto the mailing list.

Thanks all,
Allison

[Chromatic]

On Tuesday 14 November 2006 22:28, Allison Randal wrote:

> I've added responses after each recommendation, if you have any
> questions or comments pull them onto the mailing list.

Properties:
I don't remember what problem these try to solve. It's difficult to discuss
one way or the other without an example.

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.

Composition:
Jonathan suggested meeting on IRC next week after #parrotsketch. It's fine
with me.

VTABLE split:
It seems that this may depend on the ideas of the former.

-- c

[Allison Randal]

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