[Cuis-dev] PlacedMorph vs BoxedMorph

[Bernhard Pieber]

Hi Juan, Hilaire,

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.)

Just my two cents…

Cheers,
Bernhard

> Am 01.09.2024 um 17:55 schrieb Juan Vuletich via Cuis-dev <cuis-dev at lists.cuis.st>:
>
> Hi Hilaire,
>
> (inline)
> On 8/31/2024 10:56 AM, Hilaire Fernandes via Cuis-dev wrote:
>
>> 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.
>
> 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.
>
>> I am wondering if moving the extent attribute of BoxedMorph to PlacedMorph would be useful.
>
> 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.
>
>> 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.
>
> 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.
>
>> Hilaire
>>
>> --
>> GNU Dr. Geo
>> http://gnu.org/s/dr-geo/
>>
>> http://gnu-drgeo.blogspot.com/
>
> 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?
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240902/9cb80ba0/attachment.htm>