Morphs differ based on how brought to life?

Bijan Parsia bparsia at email.unc.edu
Sun Mar 25 05:09:29 UTC 2001


On 24 Mar 2001, Randal L. Schwartz wrote:

> >>>>> "Dan" == Dan Shafer <dshafer at yahoo.com> writes:
> 
> Dan> closePlayer
> 
> Dan>     super delete.
> 
> I'm pretty sure Kent Beck's "Smalltalk Best Practice Patterns" tells
> why "super XXX" should only be sent from within "XXX".  But this
> smells here.  I'd start by asking what you are REALLY doing there.
> This is not sending a message to the parent morph.  This is re-sending
> a message further up the inheritance chain, except that you're not
> re-sending anything, which is why it is suspect.
> 
> parent class != parent morph


Which makes me think of good ole NewtonScript's dual inheritence
scheme. Basically, you had proto inheritence (analogous to class
inheritence) and "parent" inheritence (or "container" inheritence). This
was really nice for specializing behavior depending on where you put a
widget (i.e, in what view).

This "2d" inheritence ended up looking like a comb as first you went
"over" your proto chain, and then your parent and its proto chain, on up.

I guess another way to think of parent inheritence is like hypercard
"inheritence", i.e., button, card, background, stack, then system.

Container inheritence works surprising well.

Just an aside!

Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list