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