[Cuis-dev] Tweaks for PreferenceNG

Juan Vuletich JuanVuletich at zoho.com
Sun May 15 08:32:43 PDT 2022


On 5/15/2022 3:20 AM, Hilaire Fernandes via Cuis-dev wrote:
>
> I changed the subject .
>
> Le 14/05/2022 à 17:49, Juan Vuletich a écrit :
>>
>> I think that #initialize should discard everything and start anew.
>
> I was lazy to tackle the problem now as it will make the class more 
> complex.
>
>> Please review the attach. It creates a new dictionary, populates it, 
>> and only then installs it as the new ThePreferences. This is a 
>> pattern that has been used in Squeak/Cuis many times.
>
> I don't really like much, it makes the class very verbose and harder 
> to understand, added redirections, but I don't have clear workaround 
> now. Analyzing now...
>

Yes. I agree. The attach includes your original proposal, with the 
tweaks to #all and #select:.

If we find the need to do better, we can think more about it.

> I am wondering: could it be possible to put Cuis in hold while 
> initializing, it will avoid race condition, and kept the class simple, 
> hum not really fancy, no idea of the implication of a such approach.
>

I think that is risky. And harder to fix when it becomes a problem.

> Another idea is to use two class variables PreferenceReadAccess and 
> PreferenceWriteAccess . In normal operation the two reference the same 
> Dictionary. During initialization, they are decoupled and 
> PreferenceWriteAccess is set to a new empty dictionary. #at: and 
> #at:put: will be rewritten accordingly to use these variables.
>

This could work wrt query accesses from same process, but would require 
a critical section to not affect other processes. Not crazy about it.

> It will keep the class simpler. I think I like this approach.
>
> What do you think? If you agree I can make write the code.
>

I think the cleaner solution would be to again separate Preference from 
Preferences, and just create a new instance of Preferences. I know, 
that's the kind of complexity you wanted to get rid of in the first place.

I think the best now is to follow your original suggestion, as in the 
attach. And if we see a real problem with this, we'll see.

> Other observations:
>
> The class method #name:description:category:type:value: is needed, 
> with it the user describes completely a new preference. It is needed 
> by external packages introducing their own preferences. For example in 
> the Locale package I have been porting a few weeks ago there is:
>
> Locale class>>initialize
>     Smalltalk addToStartUpList: Locale.
>     PreferenceNG
>         name: #useLocale
>         description: 'Use the system locale to set the system 
> language, etc., at startup.  For time-zone handling, see 
> automaticTimezone.'
>         category: #system
>         type: Boolean
>         value: false
>
> The instance creation method #name:category:value is a shorter/lazy 
> one, where the system can deduce the type and no description is 
> provided. If one instance creation should be removed it could be this one.
>
>
>>
>> BTW, I removed #select:, and renamed #all to #allPreferences. I think 
>> this makes the stuff easier to find with 
>
> #select: is needed for a preference browser. Applications introducing 
> a new category of preferences (think #drgeo category for example) may 
> want to use this selector too. I think it should be reintroduced (with 
> a better name?) it will avoid to get it reintroduced in several 
> application package.
>
> Good point on #all!
>
> Thanks
>
> Hilaire
>
> -- 
> GNU Dr. Geo
> http://drgeo.eu
> http://blog.drgeo.eu

Maybe the attach is ok for you, and we're done. Please tell.

Thanks,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
https://twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220515/8b6ceeb7/attachment-0001.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 5167-CuisCore-PossibleTweaksFor-PreferenceNG-2022May15-12h16m-hlsf.001.cs.st
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220515/8b6ceeb7/attachment-0001.ksh>


More information about the Cuis-dev mailing list