Hi everybody.

I've been watcing this thread with morbid interest - it seemed alot of
energy was going down the drain, but actually, I think that was a
premature assesment.

But I think Todd's idea here is a really really good one. I think we
have a much better chance of refactoring Morphic than we do of rewriting
anything near as cool. There's a systems law that says "separate things
that change at very different rates". The corrolary is "separate things
that have very different stakeholders" - we could use this kind of
refactoring to separate the "Morphic" programmers use to build boring
old applications, from the "Morphic" that's perfect for eToys.

So what would the whole process look like?

current state - One big blob of interdependent applications and
framework
  <add superclass BaseMorph, move up methods (but which ones?)>

new state - BaseMorph holds alot of the basic Morph frameword
functionality, but has no users, except the subclass Morph, which is
still part of a blob
  <start changing superclass for various critical, standard morphs to
BaseMorph - immidiate suspects - Buttons, PLMs, Text, SystemWindow.
We'll discover that we're missing some methods that weren't moved up
because they had what people call cruft - dependencies on subclasses of
Morph, or other eToys code. Write a new implementation, that doesn't
depend on things external to BaseMorph (but what is in, and what is
out?)>

new state - We have the framework split into two, with some of the
common morph based on the "clean part".
  <move a series of small but growing applications to use only BaseMorph
derived stuff - FileList, ChangeSorter, Browser...>
new state - we have many tools working off BaseMorph and it's
subclasses. We aren't invoking Morph very often.
  <rename Morph to EtoyMorph or some such, and remove it, and all of
it's subclasses, and everything dependent on them, early in an alpha
stage in the image cycle, making them a loadable package>

new state - we have two frameworks, one still in the image, but much
smaller, and with far more direct users, and following some rules to aid
understandability and modularity, and the second, that supports eToys,
still holds alot of "cruft".

Nice as it is, there are a few problems with this process - 
* Where's the functional limit? what is Morphic, and what is eToys?
* Other dependencies - For example, Object depends on Morph (and eToys)
too. We'll need to attack this in parallel.
* Ownership. As Daniel Joyce said, ownership is critical. Having
isolated much of the "cruft" in Morphic into a EtoysMorph system, and
removed it to a package, eToys will now proceed to die a little
everytime Squeak changes under it. Much as it does now, except more
quietly, since less people will load it. On the upside, someone can take
ownership of it, and start trimming, and cleaning and adapting it, so it
stays alive and gets better.
* Ownership 2. The BaseMorph itself will suddenly be much lighter and
simpler. As Andreas implied - useful simple stuff attracts cruft. A lot
of people will want to make it much nicer and cooler... there'll need to
be an owner. The owner, as DanielJ said, is a gatekeeper, not letting
stuff in, but as any good gatekeeper knows, if nothing was to get in,
there'd be a wall, not a gate. So the challange is to let functionality
in, but adapting the framework to fit it nicely, using patterns and all
that nice stuff.

But though the road will be rocky, I think it's a worthwhile one.

Todd, DanielJ, care to submit an initial patch, explaining what it does
and doesn't handle?
<plug>The Refactoring Browser should come in handy... </plug>

Daniel

tblanchard at mac.com wrote:
> 
> On Tuesday, February 11, 2003, at 04:32  AM, Ned Konz wrote:
> > We should be able to take all these things and make them separately
> > loadable packages. EToys, Piano Rolls, Stack Morph, Flaps, and the
> > rest are all things that are not part of a minimal Squeak system.
> 
> Yep - but first we gotta untangle them.  I might be able to help as I 
> am recently unemployed
> (job tips are welcome btw -Resume: 
> http://www.free-for-recruiters.com/Resumes/CO/1006864-Resume.html.)
> 
> > One direction I was recently thinking about is this: it wouldn't take
> > too much to make a "separate but equal" Morphic hierarchy, with some
> > minimal behavior to make it play with the existing Morphic API. Start
> > at NewMorph or something, and build the widgets you really want. Then
> > move, copy, or port over the bits of the existing Morphic that you
> > want to keep.
> 
> This sounds hard.
> 
> I was thinking of sticking a new superclass in above Morph.
> Call it ProtoMorph.  Create a simple RectangleMorph clone that derives 
> from ProtoMorph.
> 
> Stick a RectangleMorph and a ProtoRectangleMorph side by side and move 
> logic up to ProtoMorph until ProtoRectangleMorph is minimally useful.  
> Stop and reassess.
> 
> > Todd Blanchard