[Cuis-dev] The Preference model

[Luciano Notarfrancesco]

Hilaire, thanks for taking the time to write about this and bringing it up
for discussion. I’ll share some opinions from the top of my head, see
bellow:

On Wed, 27 Apr 2022 at 12:49 AM Hilaire Fernandes via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

>
>    - categoryList - an array of selector describing the categories the
>    preference belongs to. I think one selector is enough. *Opinion?*
>
> Yes, just one category for a preference sounds better, I wonder what was
the reason for allowing a preference to have multiple categories..

>
>    - changeInformee changeSelector - an object and selector to inform of
>    value changed. I don't think it is good design, it is limited to one object
>    and it should use triggerEvent. *Opinion?*
>
> Yes, makes sense.

> To overcome the limitation of Preference mode, we could have subclasses of
> Preference, each specialized in one form of preference model: list, free
> text, closure, boolean, integer, integer in an interval, color, etc. Each
> one could be then extended in a third party package with the appropriate
> widget to edit its content.
>
I agree with Mariano that a Symbol for the type should be enough, I’d
prefer to make it as simple as possible without creating lots of new
clases.

> *Preferences. *This is where the preferences are stored. The behavior is
> only in the class side, with two class variables. For me there is a concern
> with the responsibilities. For example there are methods to set the
> particular state of a Preference instance. For example #forTouch. I don't
> think it belongs there. In short the class is a bit a mess, 167 methods.
> *Opinion?*
>
>    - DictionaryOfPreferences - Hold the Preference instances.
>    - Parameters - Unclear. *Opinion?*
>
> PreferencesDictionary sounds better for a class name. I think it could
have exactly the same accessing protocol as a Dictionary (at:, at:put:,
at:ifAbsent:, at:ifAbsentPut:, etc), and internally store a Dictionary of
instances of Preference by preference name. So instead of the Preferences
class we could have an instance of PrefrencesDictionary called #Preferences
right?

The way to query the preferences is what make the class method numerous in
> Preferences.  Worst, in the base system there are Preferences methods for
> packages absent in the system, for example. The specific preferences
> instances should be instantiated in these packages, in the ad-hoc
> initialize class method, or so. *Opinion?*
>

Yes, packages could register new preferences, and they could do it be
instantiating a Preference and registering in Preferences (something like
Preferences add: aPreference) or sending a message to Preferences with all
the data to instantiate and add a new preference (something like
Preferences add: #soundsEnabled type: #boolean category: ‘system-sound’
defaultValue: true).

> Querying a Preference instance with a symbol could make Preferences much
> less cumbersome. Preferences for: #soundsEnabled, Preferences value:
> #soundsEnabled, etc. *Opinion?*
>
I would just use Dictionary semantics for querying preference values like
Prefeences at: #soundsEnabled. And for getting the actual Preference
instance similar to #associationAt: in Dictionary I would use
#preferenceAt: and #preferenceAt:ifAbsent:.

Let’s keep discussing and thinking!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220427/779d020b/attachment.htm>