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