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" <[email protected]>
> To: "Gary Chambers" <[email protected]>
> 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


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to