How about... something completely different? (Re: [squeak-dev] Re: On traits composition)

Göran Krampe goran at
Wed Dec 9 10:50:06 UTC 2009


Igor Stasenko wrote:
> 2009/12/9 Göran Krampe <goran at>:
>> Given Andreas' statement above - wouldn't it be *much* cooler to evolve
>> Smalltalk along the axis of composition instead of the axis of inheritance?
>> I have always thought that having better mechanisms for delegation would be
>> awesome, and would in most ways be much more powerful than inheritance (in
>> whichever form).
>> For example, what if one could declare that for class Foo (having ivars x,
>> y, z) any message that would result in a DNU would instead be "delegated" to
>> ivar x (and then y if no lookup is found in x either).
>> This would be equivalent to tons of messages in Foo like:
>> Foo>>name
>>        ^(x respondsTo: #name) ifTrue: [x name] ifFalse: [y name]
>> (well, kinda, you get the picture - but also, taking care of x/y returning
>> "self" in which case we probably should return the "Foo self" instead etc)
> Hmm, how is it different to inheritance?
> I mean, you can achieve similar effect by making
> an instance of Foo class superclass to be x, and x superclass to be y.

There are several differences I think. And do note I only made a "loose" 
sketch of the idea, not going into details like for example, "should Foo 
really delegate *everything* it doesn't respond to or just a specified 
protocol etc?".

A few differences off the top of my head:

- Since we delegate to ivars it is fully dynamic. We can change x and y 
dynamically. Sure, you can claim that we can change the class hierarchy 
dynamically too - but hey.

- We have the distinction of "selves". Ted mentions "self" (the part) 
and "whole" (the composition).

- We have encapsulation. Composition is black box reuse, inheritance is 
glass box :). In other words, x can not touch ivars of Foo and so on.

And probably more.

regards, Göran

More information about the Squeak-dev mailing list