Lukas Renggli a écrit :
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).
You convinced me on that point
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 ... ] ] ]
ok, but I still don't like having to express the entire absolute path. What about this : CodeHolderSetting class>>browserSettingsOn: aBuilder <setting> (aBuilder groupNamed: #highlight) parent: #codeBrowser; "create it lazily or get the existing one" label: 'Highlighting'; description: 'The Shout Syntax Highlighter'; with: [ #(charLiteral stringLiteral ...blockTemp ...) do: [ :e | aBuilder setting ... ] ] then the two solutions can live together. I will give it a try. Thanks Alain
Lukas