"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