[BUG][FIX] DeclarativePools

Daniel Vainsencher danielv at netvision.net.il
Fri Jun 6 08:16:01 UTC 2003

Tend to agree, that is, delay the file-in hassles, but get the "store
initialization code in a definer class" mechanism now.

Remember we can convert the pools to classes in 3.7 which isn't 
that far off. I think we'll have enough fun with 3.6beta stage 
as it is ;-)


Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> "Andreas Raab" <andreas.raab at gmx.de> wrote:
> > Hi Tim,
> [snip]
> > Well, you can't make an omelette without breaking a few eggs ;-)
> That's certainly true and I don't mind breaking eggs so long as people
> agree they're the right eggs and that we all want omelettes.
> > But I don't
> > see any particular problems with adopting an interim solution. E.g., use
> > declarative pools for everything that hurts us right now and leave
> > everything else as is (which means we won't have to worry about
> > WonderlandConstants or TextConstants right now). As far as I can tell, there
> > may be a few problems in some obscure places (such as you noticed in
> > SystemDictionary>>makeExternalRelease or similar) but these don't seem to be
> > overly problematic (as in: relatively easy to fix).
> The TextConstants stuff is almost completely separable so far as I can
> see and I think we (as in 'I') should do something about it anyway..
> > See above. I'm not certain I would *want* to change everything right now
> > (besides - we will have to support "dictionary style pools" for some time to
> > come anyways).
> Ah, now that's the bit that bothers me; working out how to support the
> Dictionaries used in older code that gets filed in. I'll try to
> elucidate my worry:-
> Let's say we have converted GZipConstants to be one of your nice
> SharedPool subclasses and now we try to load a package where the old
> dictionary of GZipConstants was included in the fileout (I suspect this
> is pretty rare but not infinitely so). The file will start with
> Smalltalk at: #GZipConstants put: Dictionary new!
> GZipConstants at: #foo put: 'bar'!
> and so on. Thus we lose our nice class and all the values are
> over-written. Actually of course this is a generic problem with the way
> pools have been filed out and back in; I rather wish that code had not
> been added at all. I hope to find that there are no packages that took
> advantage of it!
> Of course, there is a possibility of using ReadOnlyBindings for the
> class and trapping the exception and handling it to skip all the'bad'
> stuff. However, as we've been discussing elsewhere there's no guarantee
> that a class is held in such a binding so some extra work is needed.
> As a rather different way of handling this, perhaps it is worth
> reconsidering an earlier plan we discused, that of using classes to
> _define_ the pools rather that _be_ the pools. I don't think it's as
> nice as your SharedPool classes but it does at least avoid the hassles
> of handling the filein of old dictionaries. It doesn't solve the problem
> of out of date ones but we can't often have everything. Using
> pool-definer classes does at least give us the 'ownership' of pools, a
> place from where they came and a sort of guardian of their contents,
> which is good. Filing in a pool-definer would create the pool as part of
> the class initialize method.
> I'm not sure which is better in the long term; I prefer the elegance
> of SharedPool but don't like the filein hassles. Any other opinions
> before we spend too much time on a dead-end?
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Strange OpCodes: PHP: Put Hackers into Privileged mode

More information about the Squeak-dev mailing list