trygver at ifi.uio.no
Sun May 21 08:23:38 UTC 2006
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
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.
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
>>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".)
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
More information about the Squeak-dev