Morphs don't have names

[russellallen]

One change that post-Self morphic (Squeak/Pharo/Cuis) has from the original is that morphs have a 'properties' slot which is a dictionary for holding information about the morph.

I am wary about this as being too loose. I suspect it is a reaction to Smalltalk objects being harder to customise than Self ones.

However one useful aspect may be that morphs can be given 'names', which allows for owners to send messages directly to submorphs buried in the nested submorph tree.

At the moment, Self morphic handles this need either by stashing a copy of the target morph in a slot at the owner level or by finding the morph by position (eg morphs first morphs at: 3. Both of these are brittle and easy to break.

It may be useful to add a name slot to morphs to solve this.

But if going down that path, why have a canonical name? Maybe we should be able to tag morphs with multiple tags...

addTag: t
removeTag: t
isTagged: t
morphsTagged: t Do: blk

(label would be nicer but is used for gui stuff like labelling buttons.)

This covers a greater variety of message patterns.

[russellallen]

As a followup - one reason morph graphs are so deep in Self morphic is the pervasive use of nested rowMorphs and columnMorphs to get the desired layout. The target content morph is then several levels deep from where the owners owners owner who is sending the message.

If the submorphs were shallower this wouldn't be as much of an issue.

I think Squeak (and hence Pharo/Cuis) tried to make morphs shallower by replacing rows/columns with layoutMorphs with a pluggable layout mechanism. However this seems to have been a mixed blessing. Morphs are still deeply nested, and the layout mechanisms are less concrete and immediately understandable.

Also to mention a Squeak/Pharo/Cuis anti-pattern - searching the submorph tree for the desired morph based on its class. This pops up all over.

[sin-ack]

I think the rowMorph/columnMorph approach is great, personally. Each morph does one thing and does it well. I think we can even go further by approaching something like Flutter where things like padding/centering/etc. can be done as separate morphs. The name idea is nice but I worry about the performance of performing a tree search every time. I wonder whether it could be nice to provide a helper object which takes a name, and caches the morph internally, invalidating on morph tree changes...

[kyle-github]

I would offer up the DOM and CSS. I am not sure whether that is as a warning or a suggestion :-)

That said, the depth is only a problem if you have to manually dig to find things. Divs in the DOM can have IDs and the lookup time on those is O(1) in most (all?) browsers. They probably have a lookup table for them. Would something like that make IDs/names easier to use? You can also look up things by class as well and that is also pretty useful.

There are several layout systems that have been done before. TeX, CSS, and whatever Delphi uses all are examples to pull from. On top of that there are the various CSS libraries that are out there that try to make DOM layout easier and those expose specific kinds of models. Many are grid-based.

Isn't there a Javascript version of Morphic? Ah... yes, right here on GitHub.

[russellallen]

I'm doing a small test case for Psyche - a manager morph using a roles framework, where each morph has a set of roles associated with it, and responds to:

addRole:
removeRole:
morphsWithRole:Do:
ownersWithRole:Do:

I'll see how it goes from the perspective of ease of programming, clarity of result and performance.