Mats Nygren wrote:
> 
> 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

Mats,

There is a hierarchyMorph, the one used in the Explorer.  As far as the
model, I could also use a tree collection in my LindaTalk work.  If you
create that hierarchy off of Object (To the Geometer, for Instance) then
perhaps Morphic could start using it through composition.  If we
Plugganized the tree algorithms then we'd get blazing and I could use it
for sevaral things.  

I'm just reading a book on Constraint-based Grammars and they use a
sophisticated tree where they have a node which separates the
grammar-free parsed subtree and another subtree carries the incomplete
annotations, regarding context.

Rob

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!