<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hi Hilaire, (inline) On 8/31/2024 10:56 AM, Hilaire Fernandes via Cuis-dev wrote: <blockquote cite="mid:25bbb752-996c-4fb0-a657-2d00746be2a3@free.fr" type="cite"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> Hi, Looking at these two classes, it seems BoxedMorph has too much responsibilities and PlacedMorph not enough. Indeed, PlacedMorph has BoxedMorph as its only heir. Moreover, there is no instance of PlacedMorph. </blockquote> Not quite: PlacedMorph subclasses -> #(BoxedMorph Sample01Star Sample02Bezier Sample03Smiley Sample04Pacman Sample06EasyToGrab Sample07Clipping Sample08Form Sample09Clock Sample09ClockHourHand Sample09ClockMinuteHand Sample09ClockSecondHand Sample10PythagorasTree) . PlacedMorphs are not expected to be "boxes". That's the big difference. They are also not assumed to be resizable. That's why having an instance variable to hold something like 'extent' is not appropriate for them. <blockquote cite="mid:25bbb752-996c-4fb0-a657-2d00746be2a3@free.fr" type="cite"> I am wondering if moving the extent attribute of BoxedMorph to PlacedMorph would be useful. </blockquote> I don't think so. It is important to have a superclass for Morphs that are not rectangular shapes, or have their own idea of how to handle their size / extent. <blockquote cite="mid:25bbb752-996c-4fb0-a657-2d00746be2a3@free.fr" type="cite"> I have many situation where I am interested by a morph with extent and location but without interest to color, border, and friends. But I find myself in the situation I have to subclass BoxedMorph ending with a class with the unnecessary attributes color, border, etc. PlacedMorph is the minimum the user can add to a layout morph, because of that PlacedMorph have method with extent consideration. So it is a bit odd. </blockquote> PlacedMorphs are expected to be movable around. That's why you can add them to a layout. See the most basic example of non-rectangular morph with constant size: Sample01Star . Clearly, a Sample01Star has a well defined extent. But it can't change. And it doesn't even need to specify it: it is a consequence of how it is drawn. I think this possibility is pretty unique to Cuis' Morphic 3 framework. <blockquote cite="mid:25bbb752-996c-4fb0-a657-2d00746be2a3@free.fr" type="cite"> Hilaire <pre class="moz-signature" cols="72">-- GNU Dr. Geo <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://gnu.org/s/dr-geo/">http://gnu.org/s/dr-geo/</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://gnu-drgeo.blogspot.com/">http://gnu-drgeo.blogspot.com/</a></pre> </blockquote> I understand your need. I think a better hierachy would be something like: Morph PlacedMorph (location) BoxedMorph (extent) ColoredBoxedMorph (color, borderWidth, borderColor) Many subclasses here The problem with this approach is that a lot of code is already subclassing BoxedMorph. It may be more reasonable to add a new class between PlacedMorph and BoxedMorph. Something like: Morph PlacedMorph (location) BasicBoxedMorph (extent) BoxedMorph (color, borderWidth, borderColor) Thoughts? <pre class="moz-signature" cols="72">-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich</pre> </body> </html>