<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><font size="+1">Indeed, proper a name will be easier to pick up
        if we merge the two classes Kernel+Widget/Morph.</font></p>
    <p><font size="+1">I like the idea about the properties. I don't see
        the impact though when used in core classes. May be less
        discoverable. But with proper documentation in the classes, it
        should not be much a concern.</font></p>
    <p><font size="+1">But I guess for a core class as a BorderedMorph,
        with instances occurring in many part of the system, it is
        better to have attributes, for efficiency concerns as you
        mentioned it.</font></p>
    <p><font size="+1">If we merge these two classes, we can lower even
        more the complexity of the Morph hierarchy. That's a cool side
        benefit.<br>
      </font></p>
    <p><font size="+1">There are very little subclasses of KernelMorph
        (borderless) : <b>HaloHandle</b>, <b>Halo</b>, <b>Hand</b>, <b>PasteUp</b>.
        The vast majority are subclass of WidgetMorph (with border). It
        shows that KernelMorph (aka BoxedMorph, etc) is not useful.
        Moreover, all these 4 classes but Hand may want to use a border
        as you can read from their respective drawOn: methods.
        Concerning the Hand, it could be turned as a direct subclass of
        MoveableMorph.</font></p>
    <p><font size="+1">These discussions are nice opportunity to think
        about the whole Morph hiererachy.<br>
      </font></p>
    <p><font size="+1">Hilaire<br>
      </font></p>
    <div class="moz-cite-prefix">Le 28/12/2021 à 08:47, Luciano
      Notarfrancesco a écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CAL5GDyqPYebf8A5ag2ntuOwfHj0jz_K-xzoVA=cmJJrwzEudJw@mail.gmail.com">
      <div dir="auto">How about just BorderedMorph?</div>
      <div dir="auto"><br>
      </div>
      <div dir="auto">Also, I should mention that using “properties”
        turned out very useful in my project to separate inheritance
        from some implementation details. I have a “properties” instance
        variable in the superclass, and I use properties instead of
        instance variables in most cases. This allows to use inheritance
        more cleanly, without inheriting instance variables, and
        particular subclasses can override replace some properties by
        instance variables if desired (for example for speed). This also
        allows to make “abstract classes” that are actually concrete and
        can be instantiated.</div>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
GNU Dr. Geo
<a class="moz-txt-link-freetext" href="http://drgeo.eu">http://drgeo.eu</a>
<a class="moz-txt-link-freetext" href="http://blog.drgeo.eu">http://blog.drgeo.eu</a></pre>
  </body>
</html>