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