PoolDictionary handling (was Re: [ANN] "Upgrade to 3.6 Full Image" package on SqueakMap)

Andreas Raab andreas.raab at gmx.de
Sat May 17 15:03:05 UTC 2003


Stef,

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.

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.

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



More information about the Squeak-dev mailing list