See Preference>>preferenceValue: (that is what happens when a preference is changed). This sends notifyInformeeOfChange which can perform a zero argument selector on the "model" object/class which then eventually has to query Preferences for the value. See senders of, for instance, #addPreference:categories:default:balloonHelp:projectLocal:changeInformee:changeSelector:viewRegistry: and their associated changeSelectors.
This is how things are at the moment. Lukas' idea about pragmas is nice, essentially the same as a discovery interface. Either way the PreferenceBrowser would need changing. Regards, Gary. ----- Original Message ----- From: "Stéphane Ducasse" <[email protected]> To: <[email protected]> Sent: Wednesday, February 04, 2009 8:55 PM Subject: Re: [Pharo-project] About Preference Flow: was Re:MonticelloChangesDialog Sorry gary you lost me. I do not get change informee. On Feb 4, 2009, at 5:50 PM, Gary Chambers wrote: > Looking at the changeInformee code in Preferences/Preference, the > informee > still has to query the preference > to pick up any changes as it stands... If I understand correctly I think not. The flow is only from the Preference to the tools and after the tools only refers to its internal state (which represents a state in his own preference). Stef > > > ----- Original Message ----- > From: "Stéphane Ducasse" <[email protected]> > To: <[email protected]> > Sent: Wednesday, February 04, 2009 2:50 PM > Subject: Re: [Pharo-project] About Preference Flow: was Re: > MonticelloChangesDialog > > > > On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote: > >> Ceratainly possible. You'd want a discovery mechanism for a new >> Preference >> Browser also, otherwise who would know what the preferences are. > > no because you still define the preference in the Preference class > it just pushes the right value in MyTool and MyTool does not have to > query Preference > at runtime. > >> The method flow would still be similar, unless you had some >> redirection to >> alternate classes or methods or blocks... > > No. We use the preference when we select it. Then MyTool uses what has > been pushed > to it. and in particular it does not query at runtime preference. > So Preference becomes a removal layer on top of the system and not > something > referenced by every method flow. > >> So, in new scheme (no dependency on Preferences) the doSomething >> might be: >> >> self class shouldUseNewDiffTool >> ifTrue: [kjlhkjhjkh ] >> ifFalse: [nkjhkjkjhkj] > > Yes in mytool I deal the way I want about my preference since they are > local to me. > I do not involve preference. Preference is just a handy facade > grouping all the preferences > and an entry point to set the preferences in the tools. > >> >> >> and >> MyTool class>>preferences >> >> would answer something suitable for a preference browser. > > Could be but the package could also install the preferences in the > preferences class > > Stef >> >> >> Regards, Gary. >> >> ----- Original Message ----- >> From: "Stéphane Ducasse" <[email protected]> >> To: <[email protected]> >> Sent: Wednesday, February 04, 2009 7:58 AM >> Subject: [Pharo-project] About Preference Flow: was Re: Monticello >> ChangesDialog >> >> >>> Gary >>> >>> I have a request about the way we use preference. And this is kind >>> of >>> really really important if we want to >>> stop having spaghetti code. >>> >>> Instead of having the current situation ie >>> >>> MyTool>>doSomething >>> >>> .... >>> Preferences useNewDiffTool >>> ifTrue: [kjlhkjhjkh ] >>> ifFalse: [nkjhkjkjhkj] >>> >>> >>> and not been able to remove the preferences (or that the preference >>> is >>> just a configuration layer). >>> >>> I would like to have the preference made that way >>> >>> MyTool class>>useNewDiff >>> >>> MyTool class>> useOldDiff >>> >>> **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! >>> >>> >>> Preferences useNewDiffTool >>> MyTool useNewDiff >>> >>> I really think that we can do it that way and this way we would >>> have a >>> much more object-oriented system >>> Do you think that this is possible with polymorph? >>> I think so. >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
