PoolDictionaries and packages
tim at sumeru.stanford.edu
Fri Apr 11 21:40:24 UTC 2003
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
fileout B3DAcceleratorPlugin - the definition of the pool stuff is
file it into an image with the above removed, creating a new changeset.
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 '
poolDictionaries: Text textConstants
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
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
tim at sumeru.stanford.edu
More information about the Squeak-dev