> 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'!

To be honest, I don't see the problem. For those pools which are effectively
managed by the system (e.g., TextConstants, GZipConstants, ZipConstants etc)
any attempt to replace them in Smalltalk would *rightfully* raise an error
(think about what would happen if the pool has evolved and you try to file
in an older version). Looking over lots of code I've not found a single
place where the currently converted pools were used through #at: or another
dictionary protocol (which is precisely the reason why I haven't touched
TextConstants as it contains the TextStyles and some packages *do* register
new ones) and so while there are chances that there's some code out there
which uses the dictionary protocol I think that they are *extremely* small.
So for the "system" set of pools I feel pretty safe as long as we don't
touch TextConstants too early on.

About pools managed somewhere else: Here I claim that it's the
responsibility of the package maintainer to decide whether or not to use
declarative pools. While I think that we should generally encourage the use
of declarative pools I am not going to require people to switch at some
definitive point. If some package runs into any problems related to
dictionary pools then I'd say that the package maintainer screwed up (both
by not protecting the pool from being filed in by someone else as well as
allowing abuse of the above kind).

BTW, for any package which I (officially or not) maintain I herewith declare
that any use of Dictionaries for pools is abuse of the worst kind and will
be punished with one blue screen of death per every ten lines of executed
code! (if you're not running windows substitute the appropriate color)

> 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.

We may want to do this though I think it's a rather unlikely situation.

> 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. 

Na. Break those eggs! They stink anyway!

> 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.

Again, for those pools which were converted I think we're either fine or
people should absolutely fix that code which relies on any of the nasty
abuses of pool dictionaries. Any other code is not affected at all so unless
you abuse an existing pool all is fine. And when you abuse it I don't care
the least bit if your code breaks when filing it in.

> 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?

I don't see neither a dead-end nor a problem here. Show me a couple of
practical examples of the problems you see (we've got roughly 250 packages
on SqueakMap) and if you find more than two let's talk about it again.

Cheers,
  - Andreas