The Trunk: Kernel-dtl.331.mcz

Eliot Miranda wrote:

   Interesting!  To my mind that definition is incorrect.  I would expect the sender of a block to be the sender of the enclosing method, in which case the definition would arguably be

BlockClosure methods for accessing
sender
^self home sender

A block activation's caller would be it's sender slot, so within a block you might refer to thisContext caller.  But what is arguably a bug in my implementation is that within a block activation thisContext sender refers to the caller (the sender of value: to the activation's block) not to the sender of the enclosing method.

How about instead of faking out BlockClosure>>sender we fix MessageTally along the lines of:

MessageTally>>tallySendsTo:inBlock:showTree:

 prev := aBlock asContextWithSender: thisContext.

This should work just as well if I understand the intent of the change correctly.

Cheers,
 - Andreas

2009/12/19 Eliot Miranda <[hidden email]>:

> Hi David,
>     Interesting!  To my mind that definition is incorrect.  I would expect
> the sender of a block to be the sender of the enclosing method, in which
> case the definition would arguably be
> BlockClosure methods for accessing
> sender
> ^self home sender
> A block activation's caller would be it's sender slot, so within a block you
> might refer to thisContext caller.  But what is arguably a bug in my
> implementation is that within a block activation thisContext sender refers
> to the caller (the sender of value: to the activation's block) not to the
> sender of the enclosing method.
> I think I may have screwed up badly here and that the correct
> implementations should be
> MethodContext methods for accessing
> caller
> ^closureOrNil
> ifNil: [self error: 'this is a method activation and so has no caller']
> ifNotNil: [sender]
> sender
> ^closureOrNil
> ifNil: [sender]
> ifNotNil: [closureOrNil outerContext sender]
> BlockClosure methods for accessing
> sender
> ^outerContext sender
> and either
> BlockClosure methods for accessing
> caller
> "Since a BlockClosure is by definition not an activation it does not have a
> caller.
>  It has a sender because it is always created within the context of a
> method."
> ^nil
> or
> BlockClosure methods for accessing
> caller
> ^self error: 'this is an inactive block and so has no caller'
>
> I believe the pre-closure definitions are
> ContextPart methods for accessing
> sender
> ^sender
> BlockContext methods for accessing
> caller
> ^sender
> which to my mind is missing
> BlockContext methods for accessing
> sender
> ^home sender
> What do people think the right definitions should be?

i think the intent of this fix was to match the:

|x y |
x := thisContext sender.
[ y := thisContext sender ] value.
x == y

Since thisContext variable value depending on scope, where it used.

The really interesting question to answer is:

either we threat thisContext as implicitly declared in method's scope only:

someMethod
| thisContext |

[ [ [ [ x := thisContext ] ] ] ]

or threat as implicitly (re)declared at each level of scoping:

someMethod
| thisContext |

[| thisContext | [| thisContext | [| thisContext | [| thisContext | x
:= thisContext ] ] ] ]

> On Fri, Dec 18, 2009 at 8:36 PM, <[hidden email]> wrote:
>>
>> David T. Lewis uploaded a new version of Kernel to project The Trunk:
>> http://source.squeak.org/trunk/Kernel-dtl.331.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Kernel-dtl.331
>> Author: dtl
>> Time: 18 December 2009, 11:32:44 am
>> UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e
>> Ancestors: Kernel-bs.330
>>
>> Add BlockClosure>>sender required for MessageTally class>>tallySends:
>>
>> Harvested from Pharo (nice 4/14/2009 19:09).
>>
>> =============== Diff against Kernel-bs.330 ===============
>>
>> Item was added:
>> + ----- Method: BlockClosure>>sender (in category 'debugger access') -----
>> + sender
>> +       "Answer the context that sent the message that created the
>> receiver."
>> +
>> +       ^outerContext sender!
>>
>>
>
>
>
>
>

--
Best regards,
Igor Stasenko AKA sig.