Hi,

I have looked a little at Morphic and have a concrete proposal for
factoring:

OpenObject (extension)
   OpenSimpleTree (submorphs)
      OpenTree (owner)
        Geometer (bounds fullBounds)
           Morph (color)

And move the code up as far as possible. The particular names and other
details can be discussed of course. If this gets used the names 'submorphs'
and 'owner' should be reconsidered in its new context.

Then some Morph-functionality will be available to other uses. And
whatever is invented and added to these classes from other uses will
potentially benefit Morph. For example on may come up with a scheme for
inheriting attributes between OpenObjects (much like the class hierarchy
which can be put in this form if wanted). And if Model-protocol is added
to OpenObject (it should be) then Morphs immediately get this.

The copying, traversing and other abstract things that is used in
morphic is very useful indeed for other purposes, this will extend the
Collection traversals in useful ways. I would add a general tree/dag/graph-
Visitor to this making several operations irresistably elegant. IM(H;-)O.
And the Morphic hackers will be invited to separate their concerns a little
so that these abstract structural things doesn't have any morph-specific material
in it.

OpenObject (or OpenModel, it can easily include the Model protocol with
the extension-field 'dependents') are very useful for many purposes.
Examples: Parse trees, Python-like objects. The extension should not be
to closely associated with Dictionary, other possibility exist, in
particular a sequence of Dicitionaries like in the Class hierarchy. I have 
considered making a special version of the compiler for methods in
OpenObject-subclasses then code could deal with extended fiels with the
same syntax as ordinary field, as in Python.

OpenSimpleTree works (for reading purposes) like a list in lisp with
a builtin property list, very useful.

OpenTree has the property that a reference to any node can get the whole
tree, good for editors. I have made a tree editor that I will port to Squeak and
the present organization will work wonders for that. I'm busy with other things
now but sooner or later it will happen.

Geometer is meant to be something that knows about its place in some
geometry (2 or 3 dimensional Euclidean at present). But it does not know
about colors and other appearance-related things. This makes sense since
several operations are independent of appearance.

And then finally we have Morph a (OpenTree-) Geometer that knows its
appearance.

The Open<X> should be moved out of the Morph-category altogether.

When I tried this out some problems with deepCopier (or something) arose.

Compare this with my other post today about replying Lex Spoon on "Re:
Compiler, was Re: Block closures".

I have to go now, more on this later. Have a nice weekend.

/Mats