Ralph,
There may be a fundamental difference between Word and Smalltalk rearding 
modularization. Word is essentially a piece of source code; modularization 
here means an orderly refactoring of source packages. The surface 
separating Word from its environment is a set of well-defined required and 
provided interfaces. The same applies to any module within Word, the notion 
of a package is recursive.

Smalltalk is essentially a universe of interlinked and interacting objects. 
Class based modularization may be doomed to failure if applied to legacy 
parts. A Smalltalk module seems to be more than classes and incremental 
methods, but rather a cluster of objects with clearly defined links to 
clearly defined objects in its environment. (Classes and methods are 
objects in ST, so a program package is a special case of an object module.)

I have tried putting a facade object in front of a Morph, the idea being to 
make a component enclosing a morph substructure. It should be easy; a morph 
is only a submorph of its owner. Right? Wrong! The variety of objects that 
send messages to a simple submorph turned out to be unbelievable. And many 
of them were transient, only existing during the execution of certain 
operations. May be I gave up too easily. Or may be the number of criss 
crossing links in the Smalltalk image makes it impracticable to separate 
out an ensemble of objects without building a new morphic implementation 
from scratch.

But if we were to define a new kind of object module, we should make sure 
it is very clean and implemented in easily reviewable code.

Cheers
--Trygve


At 16:37 19.05.2006, Ralph Johnson wrote:
>On 5/19/06, Cees De Groot <cdegroot at gmail.com> wrote:
>>  the tools have
>>performance problems when trying to manage the whole image.
>
>Can you be specific?  What tools?  Can you give stories of how tools 
>failed you?
>
>>On a more philosophical stance, Squeak has grown organically. And
>>anything organic tends to get fuzzy, maybe even almost fractal,
>>borders between the various parts. Try separating a leaf from its
>>stem, on the cell level, for starters...
>
>Squeak is a bit more extreme than others, but not a lot.  As Fred
>Brooks said, all successful large systems started as successful small
>systems.  Organic growth is typical, not atypical.  Refactoring is a
>lot of hard work and Squeak doesn't have people being paid to do this
>kind of work.  But I find it hard to believe that Squeak is worse than
>Word, or Gnu EMACS, or any other large system that has been around for
>a long time.  The difference is that Microsoft pays people a lot of
>money to modularize Word.  It goes though periods of organic growth,
>and then periods of modularization as they try to reuse code across
>projects or within Word.  Most software does this.
>
>This is why I think modularizing Squeak is an interesting project,
>because we can learn lessons from it that will apply to all software.
>So, we need to write about what we are doing, the problems we
>discover, and the lessons we learn.
>
>Squeak hasn't needed to be modular enough for people to do the work to
>make it so.  Now it does.  (Well, it probably has for several years,
>so "now" means "the last few years".)
>
>-Ralph Johnson


-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway