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