Gary Chambers a écrit :
In that case perhaps the setter should expect a PreferenceValue or native and internally store one after setting its value.
Not quite clear what should be stored in the class var from the code snippet.
Perhaps the following is simpler if the PreferenceValue does the handling:
FreeTypeSettings class>>monitorTypeLCD <preference: 'LCD monitor type' type: #Boolean defaultValue: false description: 'Use of a LCD...'> ^ MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue value: false]
Then to get is
FreeTypeSettings monitorTypeLCD value
and to set is
FreeTypeSettings monitorTypeLCD value: true yes, it is better
the PreferenceValue handles the notifications...
FreeTypeSettings class>>initialize self monitorStyleLCD when: #valueChanged send: #monitorTypeLCDPreferenceChanged: to: self
PreferenceValue>>value: anObject realValue ~= anObject ifTrue: [realValue := anObject. self triggerEvent: #valueChanged with: anObject] cool, better again happy to learn :)
Tools can just pick up the pragma and not have to worry about setters, "location" etc. ok Perhaps the PreferenceValue could hold the types/description too to help tools...
FreeTypeSettings class>>monitorTypeLCD <preference> ^ MonitorTypeLCD ifNil: [ MonitorTypeLCD := PreferenceValue name: 'LCD monitor type' type: #Boolean value: false default: false decsription: 'Use of a LCD...'] could be ok for me, anyway what do you think of:
FreeTypeSettings class>>monitorTypeLCD <preference: 'LCD monitor type' type: #Boolean decsription: 'Use of a LCD...'> ^ MonitorTypeLCD ifNil: [ MonitorTypeLCD := PreferenceValue value: false default: false] Name, type and description are only useful from PreferenceBrowser point of view (preference helper) whereas a PreferenceValue is concerned by its value and its default.
Here the pragma is a simple marker to identify the selector as a preference returner.
Of course, deliberately overwriting the class var directly will mean that notification subscribers will become disassociated...
If I well understand, I consider this as a bad pratice which should be detected by a lint rule. so, it is not a problem for me Cheers Alain
Simpler the better perhaps though.
Regards, Gary
----- Original Message ----- From: "Alain Plantec" <beranger22@gmail.com> To: "Gary Chambers" <gazzaguru2@btinternet.com> Sent: Monday, March 02, 2009 11:05 AM Subject: Re: [Pharo-project] Preference refactoring again
Gary Chambers a écrit :
Hi Gary,
Looks good. Is there really a need for a PreferenceValue class though?
I'm concerned that the getter returns a different kind of object to that expected by the setter... yes, ok
FreeTypeSettings class>>monitorTypeLCD <preference: 'LCD monitor type' type: #Boolean set: #monitorTypeLCD: defaultValue: false description: 'Use of a LCD...'> ^ (MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue value: false location: self selector: #monitorTypeLCD]) value
For any preference tool the presence of the pragma is sufficient to get/set the native value and, assuming always class-side, support event triggering for changes. I'm not sure to understand. you suggest a solution like this ? : FreeTypeSettings class>>monitorTypeLCD: aBoolean monitorTypeLCD := aBoolean. self triggerEvent: #monitorTypeLCD with: aBoolean
Of course, then you do not need PreferenceValue. But I prefer PreferenceValue solution because it encapsulates the triggerEvent, the developper do not have to deal with it and it is more evolutive (it is easy to change the way events are triggered or to change the notification framework).
regarding the pragma use, I see it as only useful from supporting tools (PreferencesBrowser...). but maybe I'm wrong, let me know.
Cheers Alain