Tim and Andreas discussion on Pools
Last updated at 1:10 am UTC on 17 January 2006
Second Email
From: Tim Rowledge
Date: Fri May 30, 2003 11:23:33 PM Europe/Zurich
To: squeak
Subject: [BUG][FIX] DeclarativePools
Reply-To: The general-purpose Squeak developers list
A few weeks ago we had a useful discussion about the problems of handling pool dictionaries and concluded that it might be useful to use classes to do the job. Andreas duly produced a prototype for us and included a really neat cleanup of scope handling.
I've been checking out the code and it seems a nice step towards a solution - we should adopt it. I now have a revised version that:-
a) is fudged to make sure that all the pools are installed in the image. This is a simplistic approach pro-tem until we solve the problem of dependency in SM1.1 - the classes are small and at least it would mean we can rely on pools being there for now.
b) adds some changes to keep the 'explain' utilities working.
c) simply prevents filing out of the new kind of pools dicts; we need to work out what to do here. We could of course file out the class of the pool dict but I think that is probably not correct.
d) fix Smalltalk>poolUsers to handle the new pool classes.
There are some methods that need discussion here:-
ReadWriteStream & GZipSurrogateStream>fileOutClass:andObject: & ReadWriteStream >fileOutClass:andObject:blocking:, SmartRefStream>appendClassDefns, SystemOrganizer>fileOutCategory:on:initializing:, Class>fileOutAsHtml:, Class>fileoutSharedPoolsOn:
- all may need simplifying to drop the pool fileout.
Class removeSharedPool: won't work - is it useful anymore? Not sent and changing pools for a class is done by redfining class and using #sharing:
The file is http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas/DeclarativePools-4.sar
First Email
OK, attempting to summarize:-
pool dictionaries are difficult to handle because they are simply
globally known [1] Dictionaries that can be created, filled out and
referred to without any useful trace being left in a changeset. Since
they are referred to by classes not directly related (obviously -
directly related classes can use class variables!) that can be part of
separate packages we have an issue of deciding which package (if any)
should take responsibility for making sure the pool exists.
I think Andreas & I agree that it would be nice to have some manner of
keeping pool dictionary capability under control with some mechanism
like his B3DPoolDefiner, and further that simplifying the interface for
looking up variable bindings woud be helpful. Given some support for
package dependency in SM we could solve (or at least put off) the issue
of 'who owns the pool' by keeping them in separate small packages that
any package can point to.
My initial proposal is to build a small hierarchy of pool defining
classes. A root abstract class would provide the framework and document
what should be done, with concrete subclasses adding just the name and
specific value filling methods. 'Smalltalk poolUsers' shows 14 pool
dictionaries in use currently so we won't suffer a huge explosion of
classes. Only the abstract class would need to be in a kernel image.
A secondary proposal would be to make the pool definer classes actually
be the pool variable holders. Making use of any suitable code left over
from Andreas' experiment in cleaning up the variable binding system
could make this very simple, clean and even, gasp, intelligible.
Andreas? Anything to add or differ with?
tim
[1] actually there are a couple of methods where the pool dict lookup
takes note of 'environment' rather than insisting on Smalltalk.
