I don't see that you have done anything with Pools yet. Have I missed this? Seems like they should somehow become incorporated in Modules (or be done away with ;-). Ditto with regard to code to initialize them.
Anyhow, in case you don't know it's there, try...
Smalltalk poolUsers (di)
Nothing yet, but in fact I cut out the following from a previous, very long mail:
Speaking of which, what do you think about removing class pools? There is an equivalent mechanism in the modules: Create a submodule, define all the "pool" variables as globals in that module; any module can now "depend on" that submodule, which makes its names available to the using module, you can import all the submodule's names if you want to avoid having to qualify the names. I would love to be able to remove things to make things simpler whenever we can. Ideally, we should be able to remove more than we add. That's how you know you have an elegant solution... But perhaps we won't get quite that far.
Technically, we could replace class variables by the same mechanism: putting the former class variables as globals in the module of the class. They are now visible to all classes in the module, which is not exactly the same, but close enough and I think the simplification is well worth it: global, pool, and class variables are all replaced by module-scoped variables. In fact, there is so much scoping control in the module scheme that using any other scoping principles is now unnecessary. (I believe Alan would like it too!) When I think of it, yes, I'm clearly in favor of replacing class vars too. Legacy code can be converted mechanically quite easily.
Today I think: globals will be gone by definition, pools should absolutely go, and as per class vars, I'm still clearly for it but I can see some people complaining. (hg)
I like getting rid of Pools, but I have to say I'm opposed to dropping classVars. Partly a compatibility thing (have to think harder when exporting to/from another dialect), and partly just that classVars provide a reasonably intuitive scope already (I think (by def ;-)).
Actually I think what bothers me about dropping classVars is that then a newbie has to learn about Modules (a fair step up, I think) before he can get that kind of scope. ClassVars, on the other hand are taught in every text, and supporte in the simplest class definition template in the browser. (di)
If modules are to provide a scoping mechanism, then indeed Occam's Razor would tell us that we should ax other scoping machanisms that it subsumes — and that seems to mean pools and class variables. But if Squeak is to remain "Smalltalk", which means to me remaining reasonably compatible with the ANSI standard, then we need to support source code that uses both of these mechanisms. Perhaps one solution is to implement pools and classVars using the module scoping mechanism, rather than named dictionaries, but to make sure that the source language templates, and the ANSI declarative syntax, still works.
As I write this comment, I feel more and more uncomfortable with making Modules do double duty as both a source code management mechanism and a naming/scoping mechanism. We will delay getting the former while we get dragged down in the details and ramifications of the latter ... (apb)
