<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"/></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Juan, Hilaire,<div><br/></div><div>I think the root cause of this problem is that these concepts are orthogonal. Maybe you want a morph that can be placed but has no border or the other way around. Single inheritance is just not good at expressing this. (This would be an ideal use case for stateful traits IMO.) However, why not use composition instead of inheritance? Instead of being a BoxedMorph any morph could just have a box (with border, padding) if it needed one. There might be other useful types of decorations for morphs, e.g. labels or scrolling. (Being a subclass of PluggableMorph every PluggableScrollPane has a model although it does not have a use for it.)</div><div><br/></div><div>Just my two cents…</div><div><br/></div><div>Cheers,</div><div>Bernhard</div><div><br/></div><div><br id="lineBreakAtBeginningOfMessage"/><div><br/><blockquote type="cite"><div>Am 01.09.2024 um 17:55 schrieb Juan Vuletich via Cuis-dev <cuis-dev@lists.cuis.st>:</div><br class="Apple-interchange-newline"/><div>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
<title></title>
<div bgcolor="#ffffff" text="#000000">
Hi Hilaire,<br/>
<br/>
(inline)<br/>
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"/><p><font size="4">Hi,<br/>
</font></p><p><font size="4">Looking at these two classes, it seems
BoxedMorph has too much responsibilities and PlacedMorph not
enough.</font></p><p><font size="4">Indeed, PlacedMorph has BoxedMorph as its only
heir. Moreover, there is no instance of PlacedMorph.</font></p>
</blockquote>
<br/>
Not quite: <br/>
PlacedMorph subclasses -><br/>
#(BoxedMorph Sample01Star Sample02Bezier Sample03Smiley
Sample04Pacman Sample06EasyToGrab Sample07Clipping Sample08Form
Sample09Clock Sample09ClockHourHand Sample09ClockMinuteHand
Sample09ClockSecondHand Sample10PythagorasTree) .<br/>
<br/>
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.<br/>
<br/>
<blockquote cite="mid:25bbb752-996c-4fb0-a657-2d00746be2a3@free.fr" type="cite"><p><font size="4"><b>I am wondering if moving the extent attribute
of BoxedMorph to PlacedMorph </b>would be useful.<br/>
</font></p>
</blockquote>
<br/>
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.<br/>
<br/>
<blockquote cite="mid:25bbb752-996c-4fb0-a657-2d00746be2a3@free.fr" type="cite"><div><font size="4"> </font><br class="webkit-block-placeholder"/></div><p><font size="4">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.</font></p><p><font size="4">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.</font></p>
</blockquote>
<br/>
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.<br/>
<br/>
<blockquote cite="mid:25bbb752-996c-4fb0-a657-2d00746be2a3@free.fr" type="cite"><p><font size="4">Hilaire<br/>
</font></p>
<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>
<br/>
I understand your need. I think a better hierachy would be something
like:<br/>
Morph<br/>
PlacedMorph (location)<br/>
BoxedMorph (extent)<br/>
ColoredBoxedMorph (color, borderWidth, borderColor)<br/>
Many subclasses here<br/>
<br/>
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:<br/>
Morph<br/>
PlacedMorph (location)<br/>
BasicBoxedMorph (extent)<br/>
BoxedMorph (color, borderWidth, borderColor)<br/>
<br/>
Thoughts?<br/>
<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>
</div>
</div></blockquote></div><br/></div></body></html>