[Cuis-dev] [Preference] Category as domain name

Luciano Notarfrancesco luchiano at gmail.com
Sat Jun 4 05:10:53 PDT 2022


Interesting. I will think more about this before giving an opinion about
your proposal. But in the meantime I wonder, what if every package had a
dictionary of preferences? Would that work with the way you arranged your
code in your packages? I think this could also address some of Gerald’s
concerns regarding modularity.

On Sat, 4 Jun 2022 at 4:17 PM Hilaire Fernandes via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Hi
>
> Below redesign proposals to the PreferenceNG class and its protocol:
>
> 1) In the PreferenceNG class, ThePreferences class variable is a
> dictionary of dictionaries where its keys are the category name.
>
> 2) A preference is instantiated/updated identically with the messages
> #name:description:category:type:value: and #name:category:value:
>
> 3) To access a preference instantiated in the base image, nothing change:
>
>     PreferenceNG at: #color
>
> Internally PreferenceNG searches for the preference only in the base image
> preference categories: #system, #programming, #gui, #font.
>
> To access a preference in non base image category I propose the message
> #at:in: #at:in:put, #instanceAt:in:
>
>     PreferenceNG at: #textSize in: #zork
>
>    PreferenceNG at: #textSize in: #zork put: 12
>
>     (the instantiate method can still be used to edit a preference value:
>     PreferenceNG name: #textSize category: #zork value: 12)
>
> Then I propose shortcuts compatible with the existing protocol:
>
>     Preference at: #zork:textSize
>
>     Preference at: #zork:textSize put: 16
>
>     Preference instanceAt: #zork:textSize
>
> I will have to write a method to move the preferences in their own
> category dictionaries.
>
> Comments?
>
> Thanks
>
> Hilaire
>
> --
> GNU Dr. Geohttp://drgeo.euhttp://blog.drgeo.eu
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220604/5fc7511d/attachment.htm>


More information about the Cuis-dev mailing list