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