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?
Like this: A globally available definition should be defined in exactly one module. But in which module does a pool variable
belong?
Alsok, the module system has a precise way of controlling access to definitions, but it cannot control pool variables. Besides, pools are redundant now that there are ways of collecting global values and control access to them--with modules.
Redundancy is not necessarily a bad thing, as you could see from my message. In fact, I would argue that for the time being there probably should be a PoolCompatibilityModule allowing you to access pools both ways; either through scoped module messages or through just using the pool dictionary. With respect to where a pool variable is defined you've given the answer yourself: In the pool, of course. The pool was the only existing scoping mechanism and while not as fine-grained as a fully blown module there's still something to be said for this level of scoping. What's happening right now is that you're breaking some fundamental relations to ST80 - and I guess that'll raise a lot of questions.
This is a hopefully informative how-to for those who want to migrate their current code to work within the modular system:
http://minnow.cc.gatech.edu/squeak/HowToPortOldCodeToModules
It also links to a page with the info on converting pools.
If the above needs to be done for every least bit of code, I guess we'll have _serious_ problems to convince people to migrate to 3.3. There _has_ to be an easier way to just file in a bit of old code.
A few things to consider in this respect:
* categories vs. modules: Categorization is independent from modules. When I saw that the new scheme makes category == module I was baffled. Why can't I put two classes from different modules into the same category? Or why can't I put classes from the same module into different categories? The current notion of module == category means that we're loosing one useful level of structuring here.
* 'As yet unclassified' module: I think we've all agreed on making the module system as unintrusive as possible for the average weekend hacker. What I'm really missing is some "as yet unclassified" module which ought to be the default for your weekend hacker.
What I'm envisioning here is basically that we have (at first) everything in the "as yet unclassified" module. People will work there exactly as they did before - no harm done if you don't want to live modules. When you _do_ you have tools to re-classify and fix your module definitions in order to get a serious module.
Cheers, - Andreas