(Sorry to respond a little late to this thread...)

On Mon, 24 Apr 2000, Stefan Matthias Aust wrote:

> + Instead of waiting for the big redesign-time which will never come,
> continuous small refactorings (together with deprecating compatibility
> methods and documenting the goal towards one will refactor) will
> probably reach the goal faster.

Just wanted to pipe in and agree with this.  I think this is especially
true for a lot of Morphic.  Squeak Central may or may not do a big
redesign of Morphic in the future.  (Last I heard, it wasn't in their
schedule, but I'm not positive about this.  Any status?)

Refactoring smaller parts of Morphic so that something is expressed more
clearly, or duplicated code is factored out, is a good thing either way,
and should be encouraged.  A successful small refactoring of something
should make a major redesign at a later time *easier*, not harder.

So, let's see some refactorings submitted to this list, along with the
[FIX]es and [ENH]ancements! :-)  I know there are people out there who
have refactored/cleaned up parts of Morphic, but have been reluctant to
post their changes, since they thought a major redesign was coming soon.

(Stefan's point about documenting, and deprecating compatibility methods
is important, too...)

- Doug Way
  EAI/Transom Technologies, Ann Arbor, MI
  http://www.transom.com
  dway at mat.net, @eai.com