<br><br><div class="gmail_quote">On Wed, Dec 23, 2009 at 12:27 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/12/19 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Hi David,<br>
> Interesting! To my mind that definition is incorrect. I would expect<br>
> the sender of a block to be the sender of the enclosing method, in which<br>
> case the definition would arguably be<br>
> BlockClosure methods for accessing<br>
> sender<br>
> ^self home sender<br>
> A block activation's caller would be it's sender slot, so within a block you<br>
> might refer to thisContext caller. But what is arguably a bug in my<br>
> implementation is that within a block activation thisContext sender refers<br>
> to the caller (the sender of value: to the activation's block) not to the<br>
> sender of the enclosing method.<br>
> I think I may have screwed up badly here and that the correct<br>
> implementations should be<br>
> MethodContext methods for accessing<br>
> caller<br>
> ^closureOrNil<br>
> ifNil: [self error: 'this is a method activation and so has no caller']<br>
> ifNotNil: [sender]<br>
> sender<br>
> ^closureOrNil<br>
> ifNil: [sender]<br>
> ifNotNil: [closureOrNil outerContext sender]<br>
> BlockClosure methods for accessing<br>
> sender<br>
> ^outerContext sender<br>
> and either<br>
> BlockClosure methods for accessing<br>
> caller<br>
> "Since a BlockClosure is by definition not an activation it does not have a<br>
> caller.<br>
> It has a sender because it is always created within the context of a<br>
> method."<br>
> ^nil<br>
> or<br>
> BlockClosure methods for accessing<br>
> caller<br>
> ^self error: 'this is an inactive block and so has no caller'<br>
><br>
> I believe the pre-closure definitions are<br>
> ContextPart methods for accessing<br>
> sender<br>
> ^sender<br>
> BlockContext methods for accessing<br>
> caller<br>
> ^sender<br>
> which to my mind is missing<br>
> BlockContext methods for accessing<br>
> sender<br>
> ^home sender<br>
> What do people think the right definitions should be?<br>
<br>
<br>
</div></div>i think the intent of this fix was to match the:<br>
<br>
|x y |<br>
x := thisContext sender.<br>
[ y := thisContext sender ] value.<br>
x == y<br></blockquote><div><br></div><div>NI don't think so. Within a block thisContext is not a BlockClosure but a MethodContext (note not a BlockContext). The fix was for BlockClosure not ContextPart et al. Again "[] home sender" is the right approach (see below).</div>
<div><br></div><div>(*) That it is a MethodContext is a historical accident. My closure implementation discards BlockContext. Some time we should merge ContextPart and MethodContext into a single class Context.</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Since thisContext variable value depending on scope, where it used.<br>
<br>
The really interesting question to answer is:<br>
<br>
either we threat thisContext as implicitly declared in method's scope only:<br>
<br>
someMethod<br>
| thisContext |<br>
<br>
[ [ [ [ x := thisContext ] ] ] ]<br>
<br>
or threat as implicitly (re)declared at each level of scoping:<br>
<br>
someMethod<br>
| thisContext |<br>
<br>
[| thisContext | [| thisContext | [| thisContext | [| thisContext | x<br>
:= thisContext ] ] ] ]<br></blockquote><div><br></div><div>Not so interesting :) It has to be the latter because you have to be able to name the current context. If you need to mention the former you write "thisContext home". And so "aClosureOrContext home sender" will answer the enclosing method activation's sending context for both blocks and contexts.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
<br>
> On Fri, Dec 18, 2009 at 8:36 PM, <<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a>> wrote:<br>
>><br>
>> David T. Lewis uploaded a new version of Kernel to project The Trunk:<br>
>> <a href="http://source.squeak.org/trunk/Kernel-dtl.331.mcz" target="_blank">http://source.squeak.org/trunk/Kernel-dtl.331.mcz</a><br>
>><br>
>> ==================== Summary ====================<br>
>><br>
>> Name: Kernel-dtl.331<br>
>> Author: dtl<br>
>> Time: 18 December 2009, 11:32:44 am<br>
>> UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e<br>
>> Ancestors: Kernel-bs.330<br>
>><br>
>> Add BlockClosure>>sender required for MessageTally class>>tallySends:<br>
>><br>
>> Harvested from Pharo (nice 4/14/2009 19:09).<br>
>><br>
>> =============== Diff against Kernel-bs.330 ===============<br>
>><br>
>> Item was added:<br>
>> + ----- Method: BlockClosure>>sender (in category 'debugger access') -----<br>
>> + sender<br>
>> + "Answer the context that sent the message that created the<br>
>> receiver."<br>
>> +<br>
>> + ^outerContext sender!<br>
>><br>
>><br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</font></blockquote></div><br>