Stephen,

> This solution feels like you're trying really hard to fit 
> something into an existing mold rather than changing the
> mold itself.

Actually, no. All I've been doing here is to refactor a few protocols and
show how they *can* be put to use. I am not claiming that one has to it this
way - all I'm saying is that we could use it along those lines. So in this
way, the second part of the proposal was more like a natural fallout of the
changes.

> Would it not be better to go ahead and make the VM actually
> send the #value message...it seems like that the right thing
> to do and would buy us a lot in terms of 
> experimenting with new approaches for these kinds of things.

You lost me. How does sending #value or not to a binding affect pool
management? 

BTW, you don't need to change the VM for this - a slight compiler
modification is all that's needed. We have this modification already in
place for stores into 'other than association' bindings (such as read-only
bindings).

> Beyond that, what if pool dictionaries had their own of Behavior 
> subclass?  Their #bindingOf: implementation could give you a variable 
> binding that overrides the #value message to do some more intelligent 
> things (like be able to handle lookups of variables in parent 
> pools and such). 

Err ... again you lost me. I don't see how this relates to the issue of pool
management. Did you read Tim's message? That's what I've been trying to
address here.

> I could then imagine the ability to do something like:
> 
> PoolDictionary
>     subclass: #B3DConstants
>     variableNames: 'One Two Three'
> 
> MyNewPool
>     subclass: #B3DPrivateConstants
>     variableNames: 'Four Five Six'

You are certainly aware that the above could be done merely by providing
some "PoolDictionary" class and change it's #definition messages. So what
you're proposing above is not contrary to what I posted - it is an extension
of it.

Cheers,
  - Andreas