> Andreas? Anything to add or differ with?

Nope. I entirely agree.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Tim Rowledge
> Sent: Wednesday, May 14, 2003 6:49 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: PoolDictionary handling (was Re: [ANN] "Upgrade 
> to 3.6 Full Image" package on SqueakMap)
> 
> 
> Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> 
> > Hi tim and andreas
> > 
> > We are interested to help fixing this issue. Could one of 
> you summarize 
> > the problems because
> [snip]
> 
> OK, attempting to summarize:-
> 
> pool dictionaries are difficult to handle because they are simply
> globally known [1] Dictionaries that can be created, filled out and
> referred to without any useful trace being left in a changeset. Since
> they are referred to by classes not directly related (obviously -
> directly related classes can use class variables!) that can be part of
> separate packages we have an issue of deciding which package (if any)
> should take responsibility for making sure the pool exists.
> 
> I think Andreas & I agree that it would be nice to have some manner of
> keeping pool dictionary capability under control with some mechanism
> like his B3DPoolDefiner, and further that simplifying the 
> interface for
> looking up variable bindings woud be helpful. Given some support for
> package dependency in SM we could solve (or at least put off) 
> the issue
> of 'who owns the pool' by keeping them in separate small packages that
> any package can point to.
> 
> My initial proposal is to build a small hierarchy of pool defining
> classes. A root abstract class would provide the framework 
> and document
> what should be done, with concrete subclasses adding just the name and
> specific value filling methods. 'Smalltalk poolUsers' shows 14 pool
> dictionaries in use currently so we won't suffer a huge explosion of
> classes. Only the abstract class would need to be in a kernel image.
> 
> A secondary proposal would be to make the pool definer 
> classes actually
> be the pool variable holders. Making use of any suitable code 
> left over
> from Andreas' experiment in cleaning up the variable binding system
> could make this very simple, clean and even, gasp, intelligible.
> 
> Andreas? Anything to add or differ with?
> 
> tim
> [1] actually there are a couple of methods where the pool dict lookup
> takes note of 'environment' rather than insisting on Smalltalk.
> 
> -- 
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Strange OpCodes: QVC: Question Valid Command
>