[Fwd: Re: [ANN] Preference pragmas]
Locked
[Fwd: Re: [ANN] Preference pragmas]
 
|
and here is my answer.
Cheers Alain Hi Andreas, Andreas Raab a écrit : > Alain's implementation of preferences is an improvement on the current > preference system but it is effectively replacing one set of > dependencies with a different set of dependencies. Where previously > Preferences would be registered and stored via Preferences > addPreference:... in Alain's approach preferences get created via (the > old version): ... > or, with the latest: > > gradientButtonLook > <preference> > ^ GradientButtonLook > ifNil: [GradientButtonLook := PreferenceValue > name: 'Gradient look for buttons' > description: 'Gradient look for buttons' > parent: #uiPreferenceNode > type: #Boolean > default: false] > > In other words, a dependency (to either PreferenceNode, > PreferenceValue, RangePreferenceValue, MultiplePreferenceValue etc) is > created and stored client-side. It does not depend on a global object (Preferences) as it is now. For me, it is not a problem since preferences are declared locally in packages (exactly as in your pragma approach) > > My approach differs in such that it is aimed at being discoverable > without introducing any dependencies. I don't think so, you are introducing a dependency on a particular syntax wich is <preference: something: somethingelse: > I think it is better to rely on classes and not to depend on a flat syntax. > defaultPollPeriod > "Answer the number of milliseconds between interrupts for spyOn: > and friends. > This should be faster for faster machines." > <preference: 'Default Poll Period' > category: 'Profiling' > description: 'The default poll period (msecs) MessageTally uses' > type: #Number> > ^DefaultPollPeriod ifNil: [ DefaultPollPeriod _ 1 ] > DefaultPollPeriod := aNumber and maybe another method for the default and maybe something else for system level notification. Only a detail maybe but In our implementation, for one preference, you need to set only one declaration: and you use the preference like this: v := UIPreferences gradientButtonLook value. UIPreferences gradientButtonLook value: false. It allows system level notification because #PreferenceValue>>value: triggers a #PreferenceChanged events. An object can be declared as listener to a particular preference value like this: MyObject>>initialize super initialize. UIPreferences gradientButtonLook whenChangedSend: #gradientButtonLookIsNow: to: self. the opposite is #forget: MyObject>>release UIPreferences gradientButtonLook forget: self You can see it as a replacement for changeInformee: informeeSymbol changeSelector: aChangeSelector. > However, since this was discovered via pragmas, no dependency between > Preferences and MessageTally has been created. again, the dependency is on the syntax of the pragma > You can remove or replace the preferences implementation in the image > without any side effects whatsoever on MessageTally or its code. A > different preference implementation can discover the same preference > and present it accordingly. This allows adding preferences wherever is > convenient without needlessly introducing dependencies on a particular > preference implementation or UI. Pharo preference do not depends on a particular UI. PreferenceSupport is removeable without any side effect on the system. But I agree that it depends on the PreferenceNode hierarchy. > > > In Alain's version this would not be possible without actually > changing code since it is directly coupled to a particular preference > class and API. ok but the pragma-only declaration is poor: only flat syntax which allows only literals as parameters. the consequence is that you can't deal with one-to-many or range preference or something else you can discover later. Two examples: here the value domain is explicitly given with the help of a MultiplePreferenceValue. Each possible value of the preference is given with FixedPreferenceValue instances. themePreference <preference> ^ ThemePreference ifNil: [ThemePreference := MultiplePreferenceValue name: 'UITheme' description: 'The theme to use for UI look and feel' parent: #uiPreferenceNode type: #UITheme default: UIThemeWatery2 values: { FixedPreferenceValue name: 'Standard Squeak' description: 'Standard Squeak style' type: #UITheme value: UIThemeStandardSqueak. FixedPreferenceValue name: 'Watery 2' description: 'Similar to a nice OS' type: #UITheme value: UIThemeWatery2}] here a range preference value, again, the value domain is explicitly given. glyphContrast <preference> ^ GlyphContrast ifNil: [GlyphContrast := RangePreferenceValue name: 'Glyph contrast' description: 'Change the contrast level for glyphs. This is an integer between 1 and 100. (the default value is 50)' parent: #freeTypePreferenceNode type: #Integer default: 50 range: (1 to: 100)] If you only make use of a poor preference declaration (I consider preference pragma flat declaration as a poor flat textual declaration) it can have bad effects on the quality of the code which is using the preference. See how freetype hinting preference are currently handled. You have 4 boolean preferences wheras following declaration better fits: hintingPreference <preference> ^ HintingPreference ifNil: [HintingPreference := MultiplePreferenceValue name: 'Hinting' description: 'Changes the glyph shapes' parent: #freeTypePreferenceNode type: #Symbol default: #Light values: { FixedPreferenceValue name: 'Light' description: 'Light hinting, bla bla bla ....' type: #Symbol value: #Light. FixedPreferenceValue name: 'Full' description: 'Full hinting bla bla bla ....' type: #Symbol value: #Full. FixedPreferenceValue name: 'None' description: 'None hinting bla bla bla ....' type: #Symbol value: #None. FixedPreferenceValue name: 'Normal' description: 'Normal hinting bla bla bla ....' type: #Symbol value: #Normal}] FixedPreferenceValue instance can be also bound to more complex values than simple symbol (#Light, #Full ...) FixedPreferenceValue name: 'Light' description: 'Light hinting, bla bla bla ....' type: #FreeTypeHinting value: [FreeTypeLightHinting new]. or FixedPreferenceValue name: 'Light' description: 'Light hinting, bla bla bla ....' type: #FreeTypeHinting value: (MessageSend receiver: FreeTypeLightHinting selector: #new). Thus, the declaration is more rich. As a consequence, also with the help of the system level notification, a client code can be much more simple and well designed. I mean avoiding code like: FreeTypeSettings>>hintingFullPreferenceChanged Preferences HintingFull ifTrue:[Preferences disable: #HintingNone; disable: #HintingLight; disable: #HintingNormal] ifFalse:[ (Preferences HintingNone or:[Preferences HintingLight or:[Preferences HintingNormal]]) ifFalse:[ "turn it back on again" ^Preferences enable: #HintingFull]]. monoHinting := Preferences HintingFull. lightHinting := Preferences HintingLight. hinting := monoHinting or:[lightHinting or:[Preferences HintingNormal]]. FreeTypeCache current removeAll. FreeTypeFont allSubInstances do:[:each | each clearCachedMetrics]. NewParagraph allSubInstances do:[:each | each composeAll]. World restoreMorphicDisplay. The last point you maybe missed (which is maybe not so important) is that what we are declaring is a tree of preferences. See Snapshot attached (For now, only a poor tool version, "PreferenceTree open" to see it in action), it ilustrates well the point. An again, this kind of tool is NOT mandatory. Related package can be removed without side effect on the system because it also makes use of dynamic preference discovering with the help of Pragma. ah, the real last point is the default value: in your point of view, default values depend on value type. I can't agree with that point of view. It would mean, as an example, that every boolean preferences have false, or true as the default. The problem with non-literals then arises if you want to declare default value with pragma... ah, again. If your system relies on a <preference:truc:...> syntax. What about evolution of the system ? If you want to change all declarations, you have to find them all. As far as I know, you can't rely on standard code browser for it. And what about external tools and user application ? Gary Chambers quote: ------------------------- > The simple pragma approach I described would make it easier for the > tools though since they wouldn't need a separate model (or hang onto > the pragma) in order to work. > > Also, for user applications. Our ReportBuilder, for instance, also has > an end-user ui for preferences local to itself. Having acccess to the > default value/description withough having to find the pragma would be > easier. (Just an example, the ReportBuilder actually uses xml config > files for its prefs). ------------------------- End of Gary quote > > Bottom line: I think my approach is a necessity before Alain's > preference implementation can be usefully deployed. It allows us to > define preferences without introducing dependencies to specific > implementations, while allowing different implementations to discover > the same preferences. I do not really understand. > > I hope this makes the conceptual difference clear. Thanks for it. ...and remarks, critics, idea, improvements are welcomed. Cheers alain > > Cheers, > - Andreas > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Preference tree.png (57K)
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
Re: [Fwd: Re: [ANN] Preference pragmas]
|
|
| Free forum by Nabble | Edit this page |