> Perhaps it's worthwhile to make one thing really, really clear here: 
> I'm not
> proposing to invent some radically new
> solve-all-the-pool-namespace-lookup-messagesend-delegation-whatever
> problems.

I know. But you know I like that good ideas get throw so at any 
occasion I restate them (declarative syntax, and others :))

> We're having a real problem with managing pools which has been 
> outlined in
> Tim's message very clearly. I'm trying to give people options rather 
> than
> fixing them into one particular solution. The key to give people 
> options is
> to make the protocol simple yet general enough in order to support 
> various
> solutions.
>
> That's what I did. Introduce a single protocol for resolving names and 
> use
> it consistently. You can still use dictionaries exactly the same way 
> it used
> to be, but now you actually have alternatives.
>
> If we can *just* agree on that single protocol being used for resolving
> names then people can start inventing better more general, powerful,
> reflective mechanisms.
>
> Whatever. I don't care. Because if we can agree on a single protocol 
> then at
> least I know how to solve the problem at hand - managing these freaking
> pools in *some* way.

Exact. So go for it send a changeset with your single protocol and the 
fixes you did,
  because I do not see the point that I bump in all the details you 
bumped already
and I will really look at it to understand and push it into the 
cleaning.
I learned to hate pool in the past.

Stef



>
> Cheers,
>   - Andreas
>
>> -----Original Message-----
>> From: squeak-dev-bounces at lists.squeakfoundation.org
>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>> Behalf Of Stephane Ducasse
>> Sent: Saturday, May 17, 2003 4:39 PM
>> To: The general-purpose Squeak developers list
>> Subject: Re: PoolDictionary handling (was Re: [ANN] "Upgrade
>> to 3.6 Full Image" package on SqueakMap)
>>
>>
>> Hi andreas and other interested Pool guys
>>
>> I do not have enough distance with the problem to really have a clear
>> answer.
>> What I know is that I would like:
>>
>> 	- you guys to discuss and that we find a solution ;)
>> You know cleaning
>> the
>> 	kernel is quite a big task, so we do not want to hold
>> anybody that has
>> a good idea
>> 	or experience to propose a ready to work solution.
>>
>> 	- I think that having an explicit representation for
>> global, class,
>> and poolVariable
>> 	in the chunk format would be excellent. A real
>> declarative syntax.
>> 	PoolDefiner name: B3DConstants
>> 	
>> 	B3DConstants class>>initialize
>> 		"Initialize the pool"
>> 		PoolVar1 := 123.
>> 		PoolVar2 := #mumble.
>> 	
>> 	We could also see that in the change sorter and other
>> tool for example
>> (a bit like rosetta or Ginsu)
>>
>> 	- Why don't you introduce a common superclass
>> PoolDefiner because I
>> have the impression
>> 	that you will need that to support all kind of stuff?
>>
>> 	- Steven I'm like andreas. Puzzled ;) could you explain
>> us why value
>> is better.
>> 	I completely miss it. Anthony?
>> 	
>> 	- 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 :)?
>>
>> Stef
>> 	
>>
>>
>
>
>