[squeak-dev] The Trunk: Kernel-dtl.331.mcz

Eliot Miranda eliot.miranda at gmail.com
Sat Jan 2 23:47:57 UTC 2010


On Wed, Dec 23, 2009 at 12:27 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 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
>

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).

(*) 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.


> 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 ] ] ] ]
>

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.


>
> > 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100102/40c00da5/attachment.htm


More information about the Squeak-dev mailing list