I don't want an extra package just with the settings for every package I write. Also I don't want to have unreferenced classes in any of my packages.
But how can you then remove setting preference from your package? Magic? but so far I do not see how. Package 1 my app + class var for preferences (but no reference to preferences) Package 1-Pref reference to setting so that I can remove Package1-pref when we remove preferences.
Still that introduces a lot of dependencies between packages. In your example CodeHolder still depends on the preferences, because it depends on the CodeHolder-Preferences that in turn depend on the Preferences. Loading and unloading in the right order will be a nightmare (without having the transcript full of undeclared warnings).
No code Holder does not depend on Preference. Now CodeHolder-Pref depend on Preference but just for the declaration of preference not for its execution. And Code-Holder Does not depend on Code-Holder-Pref this is the inverse
My suggestion completely decouples the setting declaration from the setting framework. Metacello is following that pattern for its project definitions with great success.
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.
done, but I would keep also getSelector:/setSelector:
Yes, definitely.
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.
the default is optional. Do you think it is really a problem to keep it ?
Actually that was more of a question. Maybe specifying a default is also useful to reset the settings to the default value?
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.
now we have a tree of settings (group allow only one level). parent is the selector of the method which implements the parent setting (the parent node in the tree). I think it is better like this because : - you can use sender/implementor - when I implement a setting, I don't want to know/indicate the full path
Who defines that tree? Who defines the labels of this tree? Who defines the icons of that tree?
no, this is not like that because a setting declaration is never stored (I mean in a global tree somewhere) the tree is always dynamically built (no change management is to be implemented).
I imagine that the builder has some kind of a Seaside like API that allows the methods to add and configure the settings, and probably also group them into tree nodes. In the following example there is no need to use the pragma for the groups (which is ugly indeed):
CodeHolder class>>settingsOn: aBuilder <settings>
aBuilder group label: 'Code Browser'; with: [ aBuilder setting label: 'Annotation Pane'; selector: #annotationPane. aBuilder setting label: 'Auto Format'; selector: #autoFormat. aBuilder group label: 'Highlighting'; with: [ self settingsHighlightOn: aBuilder ]. aBuilder group label: 'Formatting'; with: [ self settingsFormatOn: aBuilder ] ]
I think that would also make the whole thing much easier to understand.
- one method = one setting
The configurable formatter of the refactoring browser has 23 settings. Shout, the syntax highlighter, has 108 style definitions. It simply does not scale to be forced to have to write a separate method for each setting.
- a setting method returns the setting declaration (which is never stored but only used dynamically by the settings browser)
I did not suggest to store the settings anywhere. The builder object would be passed into all <settings> methods to build the tree dynamically whenever needed.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project