[Cuis-dev] BoxedMorph padding

[Luciano Notarfrancesco]

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!

On Sun, Sep 8, 2024 at 19:43 Juan Vuletich <juan at cuis.st> wrote:

> 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
> 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/20240908/96fe1254/attachment-0001.htm>