Yes this would be much better. stef
On Feb 4, 2009, at 5:57 PM, Lukas Renggli wrote: > Why not use pragmas on accessors of the class side that would be > picked up by the preference browser? Then all state would be local to > the affected code. > > Something along these lines: > > MCMonticelloBrowser>>showAdvanceDiffTool: aBoolean > <preference: 'Show advanced diff tool' group: 'Monticello' type: > #Boolean> > > advancedDiffTool := aBoolean > > > Lukas > > On Wed, Feb 4, 2009 at 5:50 PM, Gary Chambers <[email protected] > > 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... >> >> ----- 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 >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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
