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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project