[squeak-dev] Re: [ANN] Preference pragmas

Matthew Fulmer tapplek at gmail.com
Fri Mar 6 21:22:16 UTC 2009


On Fri, Mar 06, 2009 at 09:25:07PM +0200, Igor Stasenko wrote:
> >>> gradientButtonLook
> >>>   <preference>
> >>>   ^ GradientButtonLook
> >>>       ifNil: [GradientButtonLook := PreferenceValue
> >>>                       name: 'Gradient look for buttons'
> >>>                       description: 'Gradient look for buttons'
> >>>                       parent: #uiPreferenceNode
> >>>                       type: #Boolean
> >>>                       default: false]
> 
> "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 , like
> PreferenceValue and so on.."
> 
> Then how about compromise:
> 
> gradientButtonLookPreference: preferenceManager
> <preference>
> | prefDeclaration |
> prefDeclaration := preferenceManager preferenceName: 'Gradient look for buttons'
>                       description: 'Gradient look for buttons'
>                       type: #Boolean
>                       default: false;
>                       getter: #gradientButtonLook setter: #gradientButtonLook: .
> 
> ^ prefDeclaration foo bar zork.

There is nothing wrong with a direct class refference. If
PreferenceValue is not loaded, and you reference
PreferenceValue, it will bind to Undeclared until such time as
you load PreferenceValue into your image. In the meantime,
nobody will be calling the method, as the method is only useful
for preferences to call, and it is not loaded.

So, no need to make a big fuss about direct class references.

The dependencies we do want to avoid are storing the value of
the preferences *inside* the global Preferences, rather than
using it as a view into the system. Because then Preferences are
stateful, and you will lose data if you unload them.

The whole point of this excercise is to make Preferences
stateless. 

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/



More information about the Squeak-dev mailing list