I was trying to see a good solution
would not be possible to have a family of pragmas
which behind the scene creates setting objects?
Stef
On Aug 27, 2009, at 5:41 PM, Alain Plantec wrote:
> 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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
