How about... something completely different? (Re: [squeak-dev]
Re: On traits composition)
goran at krampe.se
Wed Dec 9 10:50:06 UTC 2009
Igor Stasenko wrote:
> 2009/12/9 Göran Krampe <goran at krampe.se>:
>> 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:
>> ^(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
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.
More information about the Squeak-dev