How can we deal with Message rot?

Ralph Johnson johnson at cs.uiuc.edu
Wed Dec 27 13:07:58 UTC 2006


Jerome, thanks for the great introduction!

The 3.10 release is going to do something things that make the problem
worse, and some things that make it better.

The problem is how to make a system consistent when it is made out of
lots of components and there is no longer a single monolithic image.
One of the big advantages of an image is that it makes it easier to
make sure that the system is consistent.  As Jerome says, code that is
not in the image doesn't get updated when the image changes.  You
can't do an "all senders" to discover that it needs updating.  And you
can't do an "all implementors" to look at all the methods to infer
invariants.  As more and more people work on a system, it gets harder
and harder to make it consistent.  Is it possible to have the same
level of consistency in a system built from many componets developed
by many people that you find in the orignial Smalltalk image?

No, it isn't.  A system built by a large group cannot be as consistent
as a team built by a small group.  However, it can be consistent
enough.

The 3.10 release is going to componentize Squeak.  See my description
of Pavel Krivanek's KernelImage at
http://www.cincomsmalltalk.com/userblogs/ralph/blogView?showComments=true&entry=3342635112

The smallest image will be little more that what is necessary to run
the compiler.  It will have a text-based UI, i.e. Morphic is a
loadable package.

if we keep on ignoring code that is not part of the image and make the
image very small, then Squeak will die.  So, a major part of the 3.10
release will be an improved testing strategy.  We will have a test
server and a standard set of tests.  All changes will have to pass the
tests, which will involve loading lots of packages.  So, if you make a
change and ignore the standard packages, your change is unlikely to be
accepted.  There will be an easy way to load all the standard
packages, so if you are working in a minimal image then you can make
sure your changes will pass the tests by loading all the packages and
testing the changes in an expanded image.

Part of splitting the image into components involves having "official"
and "unofficial" components.  The official components are the ones
that the release team will update.  We'll have tests for them and make
sure that changes do not break them.  There will be a way for you to
get a component accepted as official, basically by providing a test
suite and having it pass all the existing tests.

This doesn't really answer your question of how to make a fundamental
change to Morphic.  Morphic is short on automated tests, so changes to
Morphic are more likely to  cause trouble even though they pass the
tests than changes to kernel classes.  But the idea is the same as for
any other system.  Write tests that show what you want to do, and then
make the changes, continually checking that you don't break anything
else.  Because Morphic is undertested, you'll probably have to write
some tests for Morphic to prove to yourself (and us) that you didn't
break anything.  These will be valuable beyond your particular
changes.

Most people seem to agree that Squeak needs to be modularized.  I
think that most of us do not realize the difficulties this will cause.
 The integrity of Squeak has been enhanced by its lack of modularity,
and we do not want to lose its integrity by modularizing it.  I think
that modularizing Squeak will lead to more tools to balance the
tradeoffs between componentization and consistency.

My goals as leader of the 3.10 release team are to modularize Squeak
and to develop processes for making a release that will improve the
quality of the software and make it easier to make a release.
Improved testing will be a key part of this.  I imagine that our first
few attempts will show a lot of need for improvement, and that we will
have to shift directions a few times until we come up with a good
process.  But these are the main things on my agenda.  The final 3.10
release will have lots of improvements, including new packages, new
tools, and new features.  But for me, these will be icing on the cake,
since my main goal is to figure out how to modularize Squeak without
losing the advantages of an integrated image.

-Ralph Johnson



More information about the Squeak-dev mailing list