Stephane Ducasse <ducasse at iam.unibe.ch> wrote:

> I think that this is an interesting issue. I always got problems 
> because Pool are really static and led to all kind of strange bug when 
> I tried to changed their values.
Changing the values _ought_ to work but I will concede the possibility
of case where it doesn't.
> 
> Is the value of the associated variable hardcoded in the method frame 
> or the key in the dictionary.
In squeak at least it is the _association_ from the dictionary that gets
put in the method literal frame. Bytecodes then access the value by
direct rape-and-pillage means. In VW a #value message is sent to the
association, which allows more nuanced usage by subclassing.
> 
> In general I tried to avoid to use them. But this is not really a 
> solution.
Certainly not if we want to keep using existing code and probably not in
cases where values need to be shared across claas trees.

> I like the idea of having
> 
> 	classVariableNames: ''
> > 	poolDictionaries: Text textConstants
> 
> However it does not solve really the problem of their static aspect.
True. The part it does solve is providing some feeling of ownership so
that at least we know who is controlling the values. Some syntax would
be needed to allow for multiple pools in a class as well.

Andreas used a simple technique to handle the B3D related pool that I
had not noticed; created a B3DPoolDefiner class that simply encapsulated
the creation and filling of the B3DEngineConstants pool. It doesn't
solve the possible problems of values being added or changed outside the
scope of simply doing 'B3DPoolDefiner initialize' but it does get things
into a place reasonably easy to fileout with other classes. If one makes
a changeset containing this B3DPoolDefiner to file in before any classes
that use B3DEngineConstants then it will automagically create and
populate the pool; the problem is that it does need to be filed in and
initialised before user classes. Another problem is that one needs to
remember to have this predeccesor file.

It might be a nice idea to try making a hierarchy of **PoolDefiner
classes to cover all the pools in use (and maybe get the classbuilder to
make a suitable new one if an unknown pool is referred to when compiling
a new class defn) and even seeing if the compiler could talk directly to
the class to get the required associations. This would make the class
actually be the pool, reducing the number of involved entities and
putting a little smile on the face of William of Occam. I _think_ it
wouldn't break any backward compatability.

This email is quite long enough for now!

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Don't document the program; program the document.