[squeak-dev] The Trunk: Kernel-dtl.331.mcz
Igor Stasenko
siguctua at gmail.com
Wed Dec 23 20:27:15 UTC 2009
2009/12/19 Eliot Miranda <eliot.miranda at gmail.com>:
> 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, <commits at source.squeak.org> 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.
More information about the Squeak-dev
mailing list
|