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