At a first time, I liked that solution very much but now I don't. If I understand well, if we use this pattern, then settings are not discovered on the fly anymore (and with it, I don't see the utility of the pragma using except for root declarations). the tree is hard coded is such #settingOn: methods and then you introduce dependencies between settings.
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).
which is ok if you declare your settings in a specific package or
CodeHolderSetting class>>browserSettingsOn: aManager  <setting>  ^ aManager newLevel parent: #userInterfaceSettings     withAll: {         aManager newSetting: 'Annotation Pane'; selector: #annotationPane.         aManager newSetting: 'Auto format'; selector: #autoFormat.    .... }
which is better if you do not want any setting specific package.
is it ok like that ? if yes, the only point would be the #parent symbol.
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. Also consider that with a builder you can define the tree and the settings at the same time. One package could define: " #groupNamed: creates a new group lazily or returns an existing one, this allows to extend and reuse existing groups. #groupNamed: does not depend on order, so the settings tree can be built in any order. " (aBuilder groupNamed: #codeBrowser) with: [ (aBuilder groupNamed: #highlight) label: 'Highlighting'; description: 'The Shout Syntax Highlighter'; with: [ #(charLiteral stringLiteral numberLiteral blockArg blockTemp ...) do: [ :e | aBuilder setting ... ] ] ] Lukas -- Lukas Renggli http://www.lukas-renggli.ch