Ralph,

I wish you much success.  Your idea of defining behavior by tests is a
good start.  Good tests for Morphic will be hard to write, and there
will obviously need to be a process for getting them (and any) tests
accepted for inclusion in the official suite, which will need to accept
additions, deletions, and edits over time.  Beyond that, some things
will need to break.  Sometimes, it will be that a test fails when it
should pass (overly aggressive assertions, etc.).  In other areas (e.g.
stream exhaustion), Squeak behaves very differently from other
Smalltalks, and probably should be changed.  I would further encourage
you to draw an underscore in the sand at the same time.

Modularization will involve some pain.  When it's over, I would hope to
see reasonable ANSI/cross-dialect compatibilty (including streams), and
unrestricted use of underscores in source code and the compiler.  Please
note that the latter does not have to kill single-key assignment, which
can be accomplished by optional editor behavior.

I doubt there will ever be a better time to clean up loose ends.

Bill



Ralph Johnson wrote (much snipped):
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.

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.





Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bills at anest4.anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029