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

[Hilaire Fernandes]

Hi Luciano,

Lately last night, for Cuis, I was thinking the same you described in 
your message below.

Thanks
Hilaire

Dr. Geo -- http://drgeo.eu

----- Luciano Notarfrancesco <luchiano at gmail.com> a écrit :
> Hi Hilaire,
>
> I was thinking more on the lines of moving the methods in PreferenceNG
> class to some new class, say PreferenceDictionary, and then having a 
> global
> instance Preferences for the base image, and another instance of
> PreferenceDictionary for DrGeo. My first idea before giving it much 
> thought
> was to add a new instance variable to CodePackage but now that seems
> totally unnecessary.
>
>
> On Sat, 11 Jun 2022 at 3:15 AM Hilaire Fernandes via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
> > Hi Luciano, Juan,
> >
> > Was busy elsewhere.
> > Le 04/06/2022 à 14:10, Luciano Notarfrancesco a écrit :
> >
> > 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.
> >
> > What I proposed imply one or more dictionaries per application. We can
> > make it explicit. Note however, as Juan emphasized, it will not 
> solve the
> > problem of purging the system from zombies preferences.
> >
> > Your proposal makes me remember the Windows Registry: A central 
> repository
> > of preferences/options/configurations for all apps in the system. It 
> also
> > has a hierarchical structure to support multiple users. Some of the
> > problems of this approach (in particular in Windows) are:
> >
> > I try to solve the preference problem for DrGeo needs with what we have
> > right now.
> >
> > I think it would be much better, as Luciano also suggests, to use the
> > central Preference registry only for the base image, and have a good 
> way to
> > let packages have their own.
> >
> > I will emphasis how the Pharo implementation based on Pragma solves
> > elegantly the problem:
> >
> > The methods (decorated with the ad-hoc pragma) defining the preferences
> > are removed when the application package is unload, so do the 
> application
> > preferences. There is nothing to clean up. What I like less, it is a bit
> > complex.
> >
> > 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
> >