PoolDictionary handling (was Re: [ANN] "Upgrade to 3.6 FullImage"
package on SqueakMap)
Stephen Pair
stephen at pairhome.net
Sat May 17 14:51:10 UTC 2003
Stephane Ducasse wrote:
> Hi andreas and other interested Pool guys
>
> - Steven I'm like andreas. Puzzled ;) could you explain us why
> value is better.
> I completely miss it. Anthony?
All I'm trying to say is make accessing pool vars more like message
sends and enable a pool dictionary to encapsulate access to its
variables. This way you could, for example, provide backward
compatibility if you are deprecating a variable. I might be off in my
thinking on the implementation details, but it's this idea that I'm
trying to express.
> - There's still one problem by the way - making a change to a pool
> actually
>
>> needs a recompilation of all the classes importing this pool (e.g.,
>> when you
>> add/remove a class var or another pool). It might be worthwhile to
>> make up a
>> common superclass for these 'pools' which know how to handle this
>> correctly.
>
>
> - I always hated this static construct. Everything in Smalltalk is
> dynamic except
> this point. I think that the solution should address this point too.
> Any idea beside not using them :)?
If you used a more intelligent binding, you wouldn't need to recompile,
but you might get a MessageNotUnderstood or a BindingNotFound exception
if for example you removed a variable. That seems very acceptable to me
since that happens currently if you remove a method that someone else
uses (you might even be able to make #senders show you everywhere that
your poolvar is being accessed).
It's actually because of this static construct that I avoid using
PoolDictionaries whenever possible. Instead, I accomplish the same
thing by sending a message to an object that is holding the variable
(could be a class, could be an instance). I guess I'm also saying that
I have very little use for PoolDictionaries as they are currently
implemented. In fact, if I have a large number of variables to define,
I'd almost go to the extent of hacking up something quick to define a
class with the vars and accessor methods that I need.
- Stephen
More information about the Squeak-dev
mailing list
|