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