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

Eliot Miranda eliot.miranda at
Wed Dec 9 18:58:25 UTC 2009

2009/12/9 Göran Krampe <goran at>

> Hi!
> Colin Putney wrote:
>> 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.
> Ehm... so the method doSomething implemented in anObject suddenly can
> access ivars/self of the *sender*? That feels ... odd. :)
> regards, Göran

My understanding of one way to do delegation in Smalltalk is to bind self to
the delegator and state to the delegate.  So within a delegated send, sends
to self are still understood by the delegator.  If this doesn't happen then
all you're doing is message forwarding, and that happens anyway.  This
doesn't allow the delegate to access the state of the delegator, nor does it
allow the delegator to access the state of the delegate, but it does allow
the delegator to inherit behaviour from the delegate.

The implementation of this is quite simple.  A context needs a state slot in
addition to a self slot.  References to self (explicit foo := self, and
super sends, explicit references to self) reference the self slot.  Accesses
to instance variables reference the state slot.  A normal send binds the
self and state slots to the receiver of the send.  A delegating send (a
delegation??) binds the new self to current self and state to the receiver.
 A self send within a delegate binds new self to current self and new state
to current state if new self == current self, otherwise self and state are
bound to the receiver.

One of the things I've purposely done differently in the Cog closure
implementation to VisualWorks is to provide a distinct reference to self, so
that within a closure access to self and instance variables is exactly the
same as in a method.  In VisualWorks self is a copied value of a closure and
completely different bytecodes are used to access self and instance
variables within a closure as opposed to in a method.  I did this with a
view to simplifying delegation implementation.

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Squeak-dev mailing list