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

Igor Stasenko 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.
>
> Colin
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list