<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Le 27/04/2022 à 19:36, Mariano Montone
      via Cuis-dev a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:d6e460af-0cd7-993b-e0f5-6c8094d87033@gmail.com">
      <blockquote type="cite"
        cite="mid:e7766d4a-e475-f7cc-3832-17b62a9b9381@drgeo.eu">
        <p><font size="4">I don't understand the PreferenceType
            interest, why not subclassing Preference for specific model
            and behavior. <br>
          </font></p>
      </blockquote>
      <p><font size="4">Personally I like the idea of being able to
          augment current preferences in Cuis with type information,
          without introducing new classes.</font></p>
      <p><font size="4">We could go ahead and annotate current
          preferences with preferenceType: Boolean,Integer,Color etc.<br>
        </font></p>
    </blockquote>
    <p>Using PreferenceType I fail to understand how it will reduce the
      quantity of needed classes to represent the whole model: a
      hierarchy of Preference or a hierarchy of TypePreference. The
      advantage of the former approach, the code is easier to understand
      as the behavior is concentrated in one class.</p>
    <blockquote type="cite"
      cite="mid:d6e460af-0cd7-993b-e0f5-6c8094d87033@gmail.com">
      <p><font size="4"> </font></p>
      <blockquote type="cite"
        cite="mid:e7766d4a-e475-f7cc-3832-17b62a9b9381@drgeo.eu">
        <p><font size="4"> </font></p>
        <p><font size="4">The visitor pattern makes the understanding
            more complex (your code snipped really show it) and as I
            understand it (I never used that pattern), it is for
            situation where the model can't be modified. It is not the
            case here as we are just discussing on the most appropirate
            model<br>
          </font></p>
      </blockquote>
      <p><font size="4">I think I would use a Visitor in the end in any
          case. Let's say you subclass Preference class and create
          StringPreference class. How do you decide what class of widget
          to use for editing it? You would "hardcode" the widget class
          somewhere in StringPreference class?</font></p>
    </blockquote>
    <p>This information about the widget will come from the Package
      implementing the Prefrence widget (for example, adding a widget
      method to the preference, a registery in the widget package, ...).
      In the base image, the PreferenceString will remain clean of any
      widget information.<br>
    </p>
    Hilaire<br>
    <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>