How about... something completely different? (Re: [squeak-dev]
Re: On traits composition)
siguctua at gmail.com
Wed Dec 9 07:02:07 UTC 2009
In this respect, interesting, how to avoid a pitfal of circular delegation.
x -> y -> x
if i send a message to x, and got DNU, it is automatically delegated to y,
but in same way as x could delegate to y, y could delegate to another
object , and finally some of them
in delegation chain could delegate back to x. Circle is closed, and VM
will loop forever trying to lookup a method not implemented in any of
objects in such delegation chain.
2009/12/9 Colin Putney <cputney at wiresong.ca>:
> On 8-Dec-09, at 2:24 PM, Göran Krampe wrote:
>> 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).
> Lately, I've been thinking that it would be useful to have a delegation
> operator. For the sake argument, let's use backtick, since it's not used in
> Smalltalk. The operator could be applied to the receiver in a message send,
> like this:
> `anObject doSomething
> This would cause the #doSomething message to behave like a super send. The
> selector #doSomething would be dispatched with respect to anObject, but the
> method would be executed with the sender as the receiver.
> I'm not sure what patterns of composition would emerge in a langauge that
> supported it, but it seems like the simplest way to allow one object to
> delegate to another object without inheriting from it.
Igor Stasenko AKA sig.
More information about the Squeak-dev