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

> > 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.
> 

Look at Bob Arning's idea (sent in a few hours ago)

<BobArning>You don't even need the "equal" part of "separate but equal".
Imagine a NewMorph as different as you like. Install trial versions of
the NewMorphs in a NewWorldMorph. NewWorldMorph would be a bit special,
appearing to its owner as a simple childless morph, but to its
newSubmorphs it's a whole new world. NewWorldMorph>>drawOn: could
dispatch whatever drawing messages NewMorphs supported and these
NewMorphs could interact with their siblings, blissfully unaware of the
old morphic world where your browsers and debuggers still
live.</BobArning>


First question: NewMorph would just be a subclass of Object wouldn't it?
And NewWorldMorph a suclass of NewMorph? And it needs at least a method
#drawOn: and composition logic. This would already be the nucleus of
NewMorphic.

I would like if we could persue this a bit further. Even if it doesn't
lead to THE NewMorphic it will be a good learning experience for many
here on the list and help to understand OldMorphic.

Having variants of Morphic with increasing complexity are good teaching
aids.

Hannes