On Tue, 28 Jan 2003, Anthony Hannan wrote:

> Avi Bryant <avi at beta4.com> wrote:
> > > 	2) If the answer to 1) is "yes", then couldn't the dynamic
> > > 		scoping be accomplished by using accessor
> > > 		methods instead of direct references to named objects?
> >
> > I think Anthony's code does largely that.  It doesn't do what I want,
> > however, because there's no guarantee that the values will be restored if
> > I reenter the same dynamic scope.
>
> Do you mean:
>
> foo
> 	[self bar] in: (WorldHandler newWithWorld: [x])
>
> bar
> 	thisContext outer world
>
> WorldHandler>>world
> 	^ worldBlock value

Well... almost.  If I were going to build my idea of a dynamic scope
mechanism on top of yours, it would be more like this:

foo
 |x|
 ...
 [self bar] in: (WorldHandler newWithGet: [x] set: [:v | x := v])

WorldHandler world
  ^ getBlock value

WorldHandler world: aWorld
    getBlock value: aWorld

But actually the crucial thing here (again, for me) is that x is a temp,
not an inst var, and so that binding will get copied when the stack does.

> foo
> 	[self bar] in: {#world -> [x]. #user -> [y]}
>
> bar
> 	thisContext outer world
>
> I originally rejected this because creating an array, associations, and
> blocks each time was wasteful, especially for handlers with many
> method/blocks.  But now I'm thinking the compiler can interpret this
> specially, like it does with #ifTrue:, and create a single multi-method
> block instead of many blocks and associations.  A multi-method block
> would be like a block closure except it would respond to multiple
> messages instead of just #value.  I believe Self has multi-method blocks
> (I don't know what terminology they use).

This feels to me (as does the entire mechanism, to be honest) like an
unnecessary abuse of doesNotUnderstand - I'd rather not have DNU tricks
used at so basic a level, personally.  But maybe that's just me.

Avi