I have a couple of ideas below.
> CodeHolderSettings class>>browsersHaveAnnotationPaneSetting
> <setting>
> ^ (SettingManager newSetting: 'Show annotation pane' translated)
> parent: #codeBrowsingSettingNode;
> default: false;
> target: CodeHolder;
> setSelector: #browsersHaveAnnotationPane:;
> getSelector: #browsersHaveAnnotationPane;
> description: 'If checked then the annotation pane is shown
> in browsers; it is dynamically updated with useful informations about
> the code which is currently browsed' translated
1. The pragma <setting> seems to be a bit short and quite a common
name. Could be that others use this pragma already. Maybe something
slightly longer like <systemsettings> would be better?
2. To avoid having class references from everywhere onto the system
preference package I suggest that you pass into the method a builder
object (see configurations in Seaside 3.0). Like this there are no
dependencies and no compiler warnings. This would also allow to define
multiple preferences in one method.
3. getSelector:/setSelector: should be replaced by #selector:, the
write-accessor in most cases can be inferred from the read-accessor
(see Magritte). The target can be predefined to the receiving class,
that simplifies the definition.
4. Why is there a #default:? Normally a package should already have
initialized the setting, or does it lazily when the accessor is
performed the first time.
5. I don't know what #parent: means? If this is to group the settings
of a particular application I suggest to do that in the pragma.
After this "refactoring" I imagine that the code looks like this:
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"
Note, that I would put the code directly on the class side of
CodeHolder. I don't see a reason why CodeHolderSettings are required.
If the preferences are stored in class variables one can easily access
the settings.
Cheers,
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
