Forcing a BlockContext to evaluate in current context -djb

Derek Brans brans at
Mon Feb 10 20:07:28 UTC 2003

Hi Lex,

Thank you for pointing out some of the land mines.

The reason I wanted to do this is that I knew where the block would 
eventually be evaluated and I knew that in that context I would have 
access to a method on an object that I don't have access to when I 
define the block.

I figure from what you are saying that this is not generally a safe 
practice so I managed to change the code around to work and it still 
seems clean.

Thank you

On Sunday, February 9, 2003, at 05:55 AM, Lex Spoon wrote:

> Derek Brans <brans at> wrote:
>> I want to force a block to evaluate in the current context.  How is 
>> this
>> done?
>> Example:
>> [self class] valueInCurrentContext
>> returns the class of the object that called "valueInCurrentContext"
> There may be a cleaner way.  This is going to lead to code that has
> landmines.  For example, a refactoring browser (or a refactoring human)
> will happily do "extract method" on code such as this and move the code
> to a different method and even a different class, but it would break the
> meaning of the code.  Also, it breaks the ability to do indirect calls,
> where  the real sender (in some sense) invokes an intermediate helper
> method, which in turn invokes the raw block.  It's fairly fundamental
> that methods cannot ask who invoked them (this is useful, because it
> makes methods definitely behave the same no matter where they are called
> from.)
> What are you trying to accomplish?  Are you trying to pick up variables
> from the caller, or just the caller object itself ?
> Oh yeah, one other thing is that if you *really* call a block from a
> different context, you will probably lose the dynamic safety that the VM
> normally gives you, such as that all variables will exist when you try
> to read them.  Adding the checks back adds some extra complexity.
> Lex
Nerd on a Wire: Web and Information Solutions
Website Design - Database Systems - Site Hosting
mailto:info at
For more information, visit

More information about the Squeak-dev mailing list