PS. Some more notes I forgot: Using this style of compositing pools also
allows you to 'merge' or 'split' pools. For example, consider we'd like to
have two pools, one for B3DPublicConstants and one for B3DPrivateConstants.
The pool B3DConstants might now be composed as:

Object subclass: #B3DConstants
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: 'B3DPublicConstants B3DPrivateContants'

etc. and any client can import whatever he needs. Of course, the above also
means that suddenly you got name spaces if you want to, for example:

Object subclass: #MyNameSpace
	instanceVariables: ''
	classVariables: 'Object Array Integer'

heh, heh ;-)

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.


Cheers,
  - Andreas

> -----Original Message-----
> From: Andreas Raab [mailto:andreas.raab at gmx.de] 
> Sent: Saturday, May 17, 2003 2:44 PM
> To: 'The general-purpose Squeak developers list'
> Subject: RE: PoolDictionary handling (was Re: [ANN] "Upgrade 
> to 3.6 Full Image" package on SqueakMap)
> 
> 
> Tim, Stef,
> 
> Attached is my proposed solution to this problem. It consists 
> of two parts:
> 
> #1: Radically changing the name lookup protocol to use 
> #bindingOf: (and only #bindingOf:). The attached changes do 
> this without breaking anything as a fallback-implementation 
> of #scopeHas:ifTrue: has been left in Behavior.
> 
> Now we can use any object as name space imported to a class 
> (e.g., 'pool) which - incidentally - means that other classes 
> can act as a pool themselves. Bringing us to
> 
> #2: Use class variables for 'declarative pools'. In other 
> words, make up a class like:
> 
> Object subclass: #MyPool
> 	instanceVariableNames: ''
> 	classVariableNames: 'PoolVar1 PoolVar2'
> 	poolDictionaries: ''
> 	category: 'My Pools'
> 
> and then
> 
> MyPool class>>initialize
> 	"Initialize the pool"
> 	PoolVar1 := 123.
> 	PoolVar2 := #mumble.
> 
> Now you can use 'MyPool' as a pool dictionary wherever you want, e.g.,
> 
> Object subclass: #MyClass
> 	instanceVariableNames: ''
> 	classVariableNames: ''
> 	poolDictionaries: 'MyPool'
> 	category: ''
> 
> I've attached an example to show you how this feels. While 
> I'm not saying that one has to use the above style it 
> certainly solves the problem of managing pools in a more 
> declarative way and combines both 'home' and 'initialization' 
> of pools. And no more 'do you want to file out any pools bla 
> bla bla' ;-) It's just a regular dependency.
> 
> Cheers,
>   - Andreas
> 
>