How about... something completely different? (Re: [squeak-dev]
Re: On traits composition)
stephen at pairhome.net
Wed Dec 9 21:35:07 UTC 2009
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>
>> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev