<br><br><div class="gmail_quote">On Wed, Dec 9, 2009 at 1:58 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">2009/12/9 Göran Krampe <span dir="ltr"><<a href="mailto:goran@krampe.se" target="_blank">goran@krampe.se</a>></span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<div><div></div><div class="h5"><div><br>
<br>
Colin Putney wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
`anObject doSomething<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<br></div>
Ehm... so the method doSomething implemented in anObject suddenly can access ivars/self of the *sender*? That feels ... odd. :)<br>
<br>
regards, Göran<br></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
</div><br><div>best</div><div>Eliot</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>- Stephen </div></div>