Le 29/04/2022 à 04:45, Luciano Notarfrancesco via Cuis-dev a écrit :
> We don’t want to check a value is of the correct type before setting
> it, we just want to specify the type so that a GUI tool for browsing
> and editing preferences can build appropriate widgets for each
> preference (a drop down list, a toggle button, etc). So the setter
> thing doesn’t make sense to me.
Well articulated.
>
> The dictionary as a class variable is a good idea to consider, tho,
> since it avoids creating a special PreferrenceDictionary class.
One point to consider then is the interface to access and manipulate the
preferences.
In the class side of Preference we can have the infrastructure to
access/add preference instances. We can discuss how the protocol will
look like:
* Preference at: #soundEnabled or more Smalltalkish Preference of:
#soundEnable
* Preference add: aPreferenceInstance looks odd, or better Preference
instance creation should auto-add the Preference instance to the
dictionary, after all if we create a Preference instance we want it
to be kept by the system, so the user should not need to
specifically ask the system to remember it:
Class method :
Preference
name: aSymbol
description: aString
category: aSymbol
value: anObject
type: aClassOrInstance
create an instance and add it to the dictionary. In the instance
creation we can make mandatory the description string (refuse nil or
empty string).
* Preference save: aSymbol to: aFileEntry,
Preference saveCategory: aSymbol to: aFileEntry,
Preference saveAllTo: aFileEntry
Preference loadFrom: aFileEntry
Gerald, do you see any limitation to load/save preferences when the
instances are in a class variable of Preference as Ken suggested?
Let's continue the discussion.
Hilaire
--
GNU Dr. Geo
http://drgeo.eu
http://blog.drgeo.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220429/5fddf0c0/attachment.htm>