[BUG][FIX] DeclarativePools

Tim Rowledge tim at sumeru.stanford.edu
Fri May 30 21:23:33 UTC 2003


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

tim
-- 
tim at sumeru.stanford.edu



More information about the Squeak-dev mailing list