Henrik,

> > The question is: What do we do about backward compatibility?! In my
> > case, the above was just a very simple example of a CS that I was
> > actually filing in, which used TextConstants and was 
> > _supposed_ to just work. I think we need to aim at backward
> > compatibility at the point of just filing in classes - it
> > should not be required that in order to just
> > file in an old bit of Squeak which (for instance) happens 
> > to use pool dicts we need to rewrite all the references
> > in the old code.
> 
> Umm, there is unfortunately no simple way to do any automatic 
> conversion, but simple pool initialization code should be simple
> to convert.

It's not initialization that bothers me. It's _using_ some existing pool
(like TextConstants). What happens is that when you file in such a class
(like my MumbleClass example), the file in process stores a _module_ in
the shared pools. And then things start to get horribly wrong.

> But you won't be able to use this code as proper module code 
> anyway as pools break modularity.

I don't understand this. Why would they? Pools where the only kind of
globals that were actually scoped across the class hierarchy in a
halfways reasonable way, so what's the difference between using a pool
and importing a module and why would using pools break modularity?

Cheers,
  - Andreas