PoolDictionary handling (was Re: [ANN] "Upgrade to 3.6 Full
Image" package on SqueakMap)
Andreas Raab
andreas.raab at gmx.de
Sat May 17 14:20:36 UTC 2003
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
More information about the Squeak-dev
mailing list
|