Andreas,

This solution feels like you're trying really hard to fit something into 
an existing mold rather than changing the mold itself.  Would it not be 
better to go ahead and make the VM actually send the #value message...it 
seems like that the right thing to do and would buy us a lot in terms of 
experimenting with new approaches for these kinds of things.

Beyond that, what if pool dictionaries had their own of Behavior 
subclass?  Their #bindingOf: implementation could give you a variable 
binding that overrides the #value message to do some more intelligent 
things (like be able to handle lookups of variables in parent pools and 
such).  I could then imagine the ability to do something like:

PoolDictionary
    subclass: #B3DConstants
    variableNames: 'One Two Three'

MyNewPool
    subclass: #B3DPrivateConstants
    variableNames: 'Four Five Six'

The sub-pool would have its own bindings for all six of the variables.  
By actually sending the #value message at the time of a binding, you 
could provide a way of invoking behavior when an attempt is made to 
resolve a binding.  That would enable the pool to encapsulate access to 
it's variables rather than just be a dumping ground for variables.

Just some thoughts...my head isn't really into this problem right now, 
so what I've just said may have no chance of actually working in 
practice.  ;)

- Stephen

Andreas Raab wrote:

>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
>>
>>
>>    
>>
>
>
>  
>


-- 
- Stephen
_________
Do you need:
  Web/Domain/Application Hosting?
  Mailing List Services?
  IMAP/POP3/Web Email Accounts?
  Instant Messaging Accounts hosted on your domain?

Email me for information.