<div dir="ltr"><div>Thank you for your response. All of it was interesting, but I'm just going to write up my thoughts on this part since I'm guessing it's the crux of the matter:</div><div><br></div>> Morphs, along with their code, are the visible representation and have<br>strict _visual_ containment.<div><br></div><div>I've been looking at Morphs as the intersection point where the user's direct manipulation[1] abilities connect with the data model of the application. In the case of Morphs that means I've been trying to program such that the Morphic halo actions like "Duplicate", "Move", etc are as useful to the user as I can make them.[2]</div><div><br></div><div>And it's this intersection point of the user's actions and the app's data model that I'm trying to understand better. In particular, I agree that the parent/child submorph relationship doesn't work for what I'm trying to do here. It's the tradeoffs of the other options I'm trying to feel out.</div><div><br></div><div>Let's go back to the example, but tweak it some since a Highway segment can exist even if one of the cities it connects is removed.</div><div><br></div><div>Consider a Simulation app with Cities and RadioLinks between them. The latter are represented visually as a dashed line and should never exist without a City at both ends. Our goal is for each halo action to be as useful as possible. Consider "Remove": we'd like "Remove" on a City to not just delete the city visually, but also (a) delete it from the simulation's data model, and (b) delete any RadioLink that has the city as one of its ends.<br></div><div><br></div><div>Some ways I can think of to do this:</div><div><br></div><div>1. Make RadioLink not a Morph, but rather implicit to the program. Use the Simulation's `drawOn` method to draw them and put their logic (for moving simulation packets around or whatever) inside of Simulation or City. This has the downside that users can no longer access them through the halo menu for changing their color or viewing their code. However it has the upside that it makes "Remove" on City behave the way users will expect: it will now also remove radio links.</div><div><br></div><div>2. Make RadioLink a Morph. Add custom code to `delete` for City that removes incident RadioLinks.</div><div><br></div><div>3. Make RadioLink a Morph. Generalize the solution in (2) to add a custom `dependsOn` message to Morphs so that when a Morph is removed from the Simulation, the Simulation removes any morphs that depended on it in a cascade.<br><div><br></div></div><div>Though as I type this up I realize that the particular details of this problem aren't so important to me (though I'd certainly appreciate suggestions on what people would do).</div><div><br></div><div>Rather this is an example of a whole class of problems I haven't encountered before: how to program in a way that makes the best use of powerful, builtin user actions like Morphic halos. Any reading recommendations along those lines would be very appreciated.</div><div><br></div><div>[1] In the <a href="https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html">Design Principles Behind Smalltalk</a> sense.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 26, 2024 at 4:03 PM <<a href="mailto:ken.dickey@whidbey.com">ken.dickey@whidbey.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2024-03-26 12:31, Ian Jeffries via Cuis-dev wrote:<br> <br> > For instance this might be an edge in a graph which connects two nodes. <br> > Or to use a more specific example this might be a segment of Highway or <br> > River between two Cities.<br> <br> Morphs, along with their code, are the visible representation and have <br> strict _visual_ containment.<br> <br> This is unrelated ("orthogonal") to other relations like connections <br> between nodes.<br> <br> > I'd like to say that the Highway has two parents, so if either City is <br> > removed then the Highway is removed as well. However the Morph/submorph <br> > relationship is strictly hierarchical so this isn't possible.<br> <br> You can have a glass in a bottle in a bucket, but you can't have the <br> glass in two separate buckets. ?Remove either bucket and the glass is <br> removed as well?<br> <br> The metaphor does not work in this case.<br> <br> > This makes me think the right thing to do is to place the edges at the <br> > same level in the Morph hierarchy as the nodes. Thus a Highway and both <br> > the Cities it connects would all be same-level submorphs of their <br> > parent. I can override the `delete` message of City to remove any <br> > adjacent Highways that start or end there.<br> <br> Both cities may be in a country. If you delete (nuke?) one city you <br> might update the node/highway relationships. A city may span a border. <br> Does either country strictly "contain" the city?<br> <br> > However, that would mean City needs to know about each object that <br> > might be an implicit submorph of it in this way. Another strategy would <br> > give morphs some kind of `implicitParents` field (not a real name <br> > suggestion), and when a morph is deleted it checks for any adjacent <br> > morphs that list it as an `implicitParent` and deletes those as well.<br> > <br> > Does it seem like I'm on the right track, and does anyone have <br> > suggestions for the best way to handle this?<br> <br> One way to think of this is like "creation relations". You want to <br> maintain relationships, which may themselves be represented as objects.<br> <br> E.g. one creates an automobile, but each gets its own tires, engine, <br> windshield. Deleting a GM factory does not delete the cars or their <br> engines. Deleting a road does not delete the cars.<br> <br> So my suggestion would be to use consistent object metaphors.<br> <br> I would hope you might have time to look at tutorials and examples in <br> <a href="https://github.com/Cuis-Smalltalk/Learning-Cuis" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Learning-Cuis</a><br> <br> HTH,<br> -KenD<br> </blockquote></div>