<div dir="auto">Yes, good points. And it’s not like this is going to be the final Morphic design, it will continue evolving and improving with new ideas. Thanks!</div><div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 8, 2024 at 19:43 Juan Vuletich <<a href="mailto:juan@cuis.st">juan@cuis.st</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On 9/8/2024 7:22 AM, Luciano Notarfrancesco via Cuis-dev wrote: > Interesting. I cannot give a very informed opinion because I don’t > program with Morphic very often, but I have some doubts about using > inheritance for this (and why not for other properties? ColoredMorph, > BorderedMorph, etc?). I wonder if it could be implemented with > properties instead (optional properties, that a morph might have or > not), or by composition. The reason to not use properties and make it > an instance variable is for speed? > > Well, it is about code complexity. It is not about wether it is an ivar of a property, but about how much code is needed to implement it. I think that using composition would lead to a lot of additional code, that would take more time to browse and understand, and more stuff to hold in your head. I'd like to be proven wrong, though (with a specific implementation we can all look at and discuss!). WRT colors and borders... Yes. Design is not an exact science at all. I think that conflating together "being a box aligned with coordinate axes", "having a fill color" and "having an (optional) colored border" together make for a compact way (minimum set of classes and methods) to do these three features, especially on a single inheritance system. Some morphs saying "I don't care about border, I'll ignore that" is less distracting that "yeah, I might have padding, go learn what that means, and how it is used elsewhere but not here, because I'll ignore it". So, it is a thin line. The trade offs of single inheritance vs. multiple, traits, prototypes, composition, etc, have been the focus of discussions about dynamic language design for decades. Smalltalk is a single inheritance system, and my aim is to use that to get code that is clear, easy to understand and adapt to new knowledge as we learn. Software design is, of course, a creative activity, and (in my opinion) there are no rules carved on stone. Each time we need to consider the options and pick one. And of course, the hierarchy is flexible enough for anyone wanting a specific subset of these features, or any other design approach, to build their own subhierarchy of LocatedMorph. I hope this makes sense. Thanks, -- Juan Vuletich <a href="http://cuis.st" rel="noreferrer" target="_blank">cuis.st</a> <a href="http://github.com/jvuletich" rel="noreferrer" target="_blank">github.com/jvuletich</a> <a href="http://researchgate.net/profile/Juan-Vuletich" rel="noreferrer" target="_blank">researchgate.net/profile/Juan-Vuletich</a> <a href="http://independent.academia.edu/JuanVuletich" rel="noreferrer" target="_blank">independent.academia.edu/JuanVuletich</a> <a href="http://patents.justia.com/inventor/juan-manuel-vuletich" rel="noreferrer" target="_blank">patents.justia.com/inventor/juan-manuel-vuletich</a> <a href="http://linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer" target="_blank">linkedin.com/in/juan-vuletich-75611b3</a> <a href="http://twitter.com/JuanVuletich" rel="noreferrer" target="_blank">twitter.com/JuanVuletich</a> </blockquote></div></div>