On Wed, Dec 9, 2009 at 1:58 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
> 2009/12/9 Göran Krampe <goran at krampe.se>
>
>> 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.
>
> best
> Eliot
>

Back at the turn of the century (I like saying that), I did exactly this for
squeak...there was an unused inst var in the context (receiverMap IIRC) and
I used it to separate the receiver from the state holder.  I added a
delegation bytecode as well as a primitive (but I never modified the
compiler to actually produce the bytecode).  I also modified message lookup
a bit to enable Self style multiple inheritance.  Adam Spitz even went so
far as to use it to recreate the Self inspectors in squeak.

- Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091209/13c66f7a/attachment.htm