Hannes Hirzel wrote:
> 
> I like the fact, that pools are now globals defined within a module. I
> didn't like the pools. I as well like that if something new is introduced
> something old is phased out.

I tend to agree, assuming the new functionality is roughly a superset of the old.

Although phasing out shouldn't necessarily be instant. :)  Maybe some sort of PoolCompatibilityModule would make sense, I don't know.

> On Sun, 3 Feb 2002, Andreas Raab wrote:
> >
> > * 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.

Hmm... the way that classes seem to be organized in modules in 3.3alpha seems pretty similar (though not identical) to how they were organized in categories before. (e.g. the classes in the Language-Core-Objects module are the same ones that were in the Kernel-Objects category)  They also have the same sort of hierarchical structure.

I suppose you could have some sort of grouping by category which cross-cuts the grouping by module, but I think people would tend to group classes in modules similarly to how they would have grouped them in categories.  So, IMHO, I'd prefer to see categories dissappear as a separate entity.

> > * '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.

I sort of agree with this.  Although I confess I haven't really tried hacking around in 3.3alpha enough yet to tell if the weekend hacker is hampered by modules or not.  But I agree that it would be nice to have some sort of default module that new classes would go into without having to do anything. (sort of like the current changeset)

Hannes Hirzel wrote:
> 
> I do not yet fully understand the concept of DeltaModules. If I alter an
> existing class (for example add a new method to the class String), where
> does the addition go to? Into a DeltaModule? Which one?
> 
> (I read the page on DeltaModules: http://minnow.cc.gatech.edu/squeak/2063)

I think Goran's recent summary was pretty good.  It sounds like the DeltaModule would be relative to String's base module (Language-Collections-Text), but you could include this DeltaModule with your own module.

(That's all fine & dandy, but I actually have some issues with whether DeltaModules will be able to handle purely additive class extensions in such a way that, e.g. the non-core Morph methods could be split off into different DeltaModules which don't interfere with each other, but could still all be loaded at the same time as part of a standard Squeak release.  But I need to look into it further, and it should probably be the topic of a separate message...)

Anyway, I'm also glad that the modules system is in place and the divvying up can begin.  I'm sure there will be plenty of discussion of the modules system and any possible modifications as everyone starts to really use it...

- Doug Way
  dway at riskmetrics.com