So what are we trying to accomplish?  Dan listed a set of "desiderata" that 
I can whole-heartedly support.  However, I would like to step up one level 
before plunging into the details.

My understanding is that a common goal is the elimination of the all 
encompassing, monolithic image. I can't argue with that goal and I don't 
think I need to reiterate all reasons this is desirable.  However, there 
are a lot of different  reasons that different constituencies have for 
wanting to see this happen.  I don't necessarily believe that one solution 
will make everybody happy.  I also think this may be one reason that there 
appears to be a lack of consensus on an approach to modularity.  Different 
people are trying to solve different problems.

If one tool won't do the job then the next simplest  thing is to have 
exactly two tools that collective will.  For conquering the monolithic 
image, I'm going to argue that the two tools we need are "components" and 
"modules".   Clearly, I need to define what I mean by this terms.  I'll 
start by trying to list some distinguishing characteristics:

Function		Components			Modules
------------------------------------------------------------------------------------------
Organizes		behavior			definition of behavior
When			runtime				development time
composition		dynamic			static
coupling		loose				tight
via			object refs/messages		inheritance/naming/syntax, etc.

Roughly speaking Components correspond to COM or CORBA objects, DLLs, SLLs 
in Visual Smalltalk, etc.

Roughly speaking Modules correspond to Java source files, Envy projects, 
TEAM/V packages, Smalltalk change sets.

Modules are all about organizing and managing code, Components are all 
about composing functionality (behavior).  Modules are used to create 
components.

Most module systems end up have some (usually weak) component-like 
characteristics. Most component systems have some (usually weak) 
module-like characteristics. To me, all of the various systems I've heard 
described in this discussion appear to fit primarily in one or the other of 
these categories with some features that are more appropriate to the 
other.  (Here is my first crack assignment based upon limited 
visibility.  Component systems: Environments, OASIS, (I don't really know 
enough about either but this is my impression) , Pope's selector ideas. 
Module systems: Pelrine's work, change sets). My impression is that people 
who are primarily thinking about component issues have problems with module 
systems because they don't see what they are looking for visa versa. Most 
of my work with modularizing Smalltalk has been on the module 
side.  However, I think there is a real place for the component view. Many 
of the rough edge I encountered in module systems have been in areas where 
they have tried to support component like usage.

So here's my strawman position: Squeaks needs both a module architecture 
and a component architecture. They should be designed to be complementary 
to each other. The module system should stick to development time 
issues.  The component system should stick to runtime issues. Globally, 
some people should be thinking about how to slice the image into components 
and modules.

Allen