(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@mat.net, @eai.com
squeak-dev@lists.squeakfoundation.org