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 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
squeak-dev@lists.squeakfoundation.org