>
> Sure, because you still want to be able to declare the settings
> anywhere. And you want to be able to add settings methods as class
> extensions to other classes. This is all possible, the only difference
> is that the settings method has one argument and therefor no
> dependency to anything whatsoever (which is absolutely crucial).
CodeHolder class>>systemSettings: aBuilder
<systemsettings: 'Code Browser'>
aBuilder newSetting
label: 'Show annotation pane' translated;
selector: #browsersHaveAnnotationPane;
description: 'If checked then the annotation pane is shown ...'.
aBuilder newSetting
"defines more settings for that group"
but lukas this is not because systemSetting:
does not refer to setting classes that there is no dependency.
newSetting and all the rest will introduce a dependency.
> Yes, that would solve the problem of the 200 preferences. I still
> prefer using a builder API, it would make it easier much easier to
> read and build. Also consider that depending on { }-constructs for
> settings declarations adds a dependency to Squeak/Pharo/GemStone,
> because these array constructs are not part of of any language
> specification.
well....
at one point we should move.
Because we should ideally get rid of #()
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
