>
A few days ago I complained about how filing out a ChangeSet did not 
include the pool dictionaries used by classes originally added by the 
file that was used to create the change set.
Umm, trying to explain that a bit better:-
B3DAcceleratorPlugin uses a pool dictionary, shared with several other 
classes.
fileout B3DAcceleratorPlugin - the definition of the pool stuff is 
included
later...
file it into an image with the above removed, creating a new changeset.
Do work.
file out changeset.
Whoops, no pool dictionary stuff in file!

This seems to me to be a big annoyance to anyone maintaining a package. 
Looks to me like it adds a sizable burden of having to fileout added 
classes manually and assembling packages. Yuck.

What should we do about pool dictionaries? They've always been a bit of 
a pain to live with.
  - we could stop using them.
  - we could change changeset fileout to include the definition along 
with any added class definition
  - we could change changesets so that adding a class means no method 
changes to that class are recorded separately (which used to be the 
case once upon a time) and thus the entire class is written out 
(including pools)  with the changeset.

...and probably many other possibilities.

I think one of the big irritations with pools is that they don't really 
belong to anyone and so it is tricky to work out who should do anything 
with the definition. The state is only in the actual object and there 
may be no record at all of what should be in there. If you fileout a 
class that uses a pool, should it really include a description of the 
pool? After all, other classes could be using it and changing the 
values or adding more. Perhaps if a changeset includes <all> the 
classes that refer to a pool one could feel safe! In many respects I'd 
prefer to use class variables and access them (for other classes) by 
good old message sends but I can imagine some people might feel that 
this would impact performance too much.

An interesting possibility came up whilst talking about this with 
Craig, one that might provide some useful leverage; change the class 
defn message to cope with  something like:-
Object subclass: #Fooble
	instanceVariableNames: 'alpha bravo charlie '
	classVariableNames: ''
	poolDictionaries: Text textConstants
	category: 'Tools-Changes'
ie instead of a string that names global (that is assumed to be a 
suitable dictionary) we pass an actual suitable object.  This would at 
least provide some sort of ownership for the pool (ie Text class in 
this case) and a place where it is created and maintained - and filed 
out!

Now this is only a rather small part of the work of maintaining 
packages so let's not get too hung up on small nitpicking about pools, 
but a solution to the real problem does seem t ome to be pretty 
important.

tim
-- 
tim at sumeru.stanford.edu