Stéphane Ducasse a écrit :
> On Aug 27, 2009, at 4:47 PM, Lukas Renggli wrote:
>
>   
>>> I see. Let us reply alain and we talk about that at ESUG satruday or
>>> sunday.
>>>       
>> Yes, let's do that. I will arrive saturday evening.
>>     
>
> Yes it will be a busy week.
>   
>>>> Why isn't a setting simply a variable local to the package, and the
>>>> setting-description a separate object (method) that can also be
>>>> packaged separately?
>>>>         
>>> it is. Normally alain is transforming all preferences into class
>>> variable of the package
>>> then I imagine that we should describe the setting so that a browser
>>> can browse and
>>> change the value of the setting. The flow should be local to the  
>>> class
>>> and not going via
>>> a global like Preference. So probably the setting description should
>>> be class extension.
>>> But there is something I should understand deeper.
>>>       
>> Maybe I am missing something, but to me it looks like the value of the
>> setting is stored within its setting instance. This should be
>> separate, because Seaside for example should not be forced to care
>> about the settings, but an extra package might provide the
>> setting-descriptions to the existing accessors so that the server can
>> be started/stopped through the Pharo preference pane.
>>     
>
> Yes!
>   
I agree it can be good to clearly separate a setting value from  its  
specification.
It means that a setting should know how to set/get the
value from an object instead of directly store the value.
I see at least three drawbacks:
(1) the setting declaration is more complex, (2) a setter and a getter 
have to be implemented for each setting + the setting specification 
(three methods instead of only one) (3) the change notification feature 
is lost (see section 7.2 from the SettingManager comment)

Cheers
Alain
> _______________________________________________
> 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

Reply via email to