Andreas Raab a écrit :
On 4/28/2010 11:32 PM, Stéphane Ducasse wrote:
Good but what is your point?
Compatibility and simplicity.
Come on Andreas, "simple" is not so much more precise than "cool"
and I don't think that having:
------------------ Editor class>>blinkingCursor ^ BlinkingCursor ifNil: [ true ]
EditorSetting class>>editorSettingsOn: aBuilder <systemsettings> (aBuilder setting: #blinkingCursor) label:'Blinking Text Cursor') parent: #Morphic; target: Editor; description: 'When true, the text cursor will blink.' -------------------
is so much more "complicated" than
------------------- Editor class>>blinkingCursor <preference: 'Blinking Text Cursor' category: 'Morphic' description: 'When true, the text cursor will blink.' type: #Boolean> ^ BlinkingCursor ifNil: [ true ] -------------------
You prefer UI+domain mixing, we prefer UI separated from domain. And yes, the SettingBrowser implementation could be improved. I know, but I'm happy because it can be removed or remade without any other consequence. And compare it to the PreferenceBrowser ...
Cheers Alain
On 4/29/2010 3:21 AM, Alain Plantec wrote:
Andreas Raab a écrit :
On 4/28/2010 11:32 PM, Stéphane Ducasse wrote:
Good but what is your point?
Compatibility and simplicity.
Come on Andreas, "simple" is not so much more precise than "cool"
That comment deserves a more detailed exploration than I want to put into this message. You can find my response here:
http://squeakingalong.wordpress.com/2010/04/30/measuring-simplicity/
and I don't think that having:
Editor class>>blinkingCursor ^ BlinkingCursor ifNil: [ true ]
EditorSetting class>>editorSettingsOn: aBuilder
<systemsettings> (aBuilder setting: #blinkingCursor) label:'Blinking Text Cursor') parent: #Morphic; target: Editor; description: 'When true, the text cursor will blink.' -------------------
is so much more "complicated" than
Editor class>>blinkingCursor <preference: 'Blinking Text Cursor' category: 'Morphic' description: 'When true, the text cursor will blink.' type: #Boolean> ^ BlinkingCursor ifNil: [ true ]
You're right, by itself it may not be "so much more complicated". But isn't this forgetting a few things? Like for example, that not only are you adding the extra method, but also an extra class and an extra package? This gets you from a single entity (the domain code) to four entities (the domain code, the builder method, class and package). In terms of both conceptual and interface simplicity that seems significant (and a dozen of messages in the builder all add to interface complexity).
BTW, I want to point out something important here. I'm not saying your approach is "bad". Good and bad, black and white, are not categories that I use for evaluating software design. I leave that to the people with overly simplified views on software development ;-) There are only different trade-offs for different goals. Your approach is perfectly reasonable for a given set of goals and trade-offs. If there is a need to have specific fine-grained control over the UI to particular preferences, I would choose precisely the same approach - make a package with views for the values that I want to modify. It's a perfectly fine approach for such a set of goals.
Moreover, "simplicity" isn't an absolute attribute of software. Simplicity is a tradeoff. It is often worthwhile to trade off simplicity, for example when adding valuable new features.
So my claim here is not about "good" and "bad". My claim is this:
1. The approach in Squeak is measurably simpler than yours. It may not fit your goals, you may need a different approach, that's quite possible. But there are numbers we can put on things to compare them and if we put the numbers on then Squeak's approach is simpler.
2. Because of the difference in interface complexity, I expect Squeak's approach will be easier to support in the long term. There's no proof for that, but I think the claim is valid, and I will watch the future developments in both Pharo and Squeak with interest.
3. Your initial design choice of using a builder framework for preferences implied the later complexity. Because the approach requires adding non-domain code to core classes it creates pressure to put this code elsewhere and to package that code separately. It's a valuable lesson about the impact of early design choices.
You prefer UI+domain mixing, we prefer UI separated from domain.
I'm missing something. What UI+domain mixing? There is no UI code in Squeak's preference tags. There is only domain code and a method tag for discovery of the preference. Only Pharo has UI (builder) code; there is no equivalent in Squeak's preference tags.
And yes, the SettingBrowser implementation could be improved. I know, but I'm happy because it can be removed or remade without any other consequence. And compare it to the PreferenceBrowser ...
I'm not certain what your point here is. I'm only talking about preference declaration, not about how the preference browser functions. PreferenceBrowser itself is reloadable in Squeak 4.1 and one of the packages that I customarily unload for creating smaller images, because I'm quite happy to set my preferences by sending message to objects directly :-)
Cheers, - Andreas
Steve Wessels wrote above
<citation> Unifying the docking bar and world menu registry is a good idea and I would like to see a uniform approach. I'm frankly unattached to how we do it just that we get over this and do it. It's an old problem with multiple solutions proposed in the past. We should pick a strategy and go forward. And to further minimize churn I recommend that if someone is going to write this code it should be stated here and we can all evaluate it. </citation>
I am not attached to a particular solution either.
Are there any news regarding a menu registry solution? Is somebody of the commiters working on a solution?
--Hannes
On 4/30/10, Andreas Raab andreas.raab@gmx.de wrote:
On 4/29/2010 3:21 AM, Alain Plantec wrote:
Andreas Raab a écrit :
On 4/28/2010 11:32 PM, Stéphane Ducasse wrote:
Good but what is your point?
Compatibility and simplicity.
Come on Andreas, "simple" is not so much more precise than "cool"
That comment deserves a more detailed exploration than I want to put into this message. You can find my response here:
http://squeakingalong.wordpress.com/2010/04/30/measuring-simplicity/
and I don't think that having:
Editor class>>blinkingCursor ^ BlinkingCursor ifNil: [ true ]
EditorSetting class>>editorSettingsOn: aBuilder
<systemsettings> (aBuilder setting: #blinkingCursor) label:'Blinking Text Cursor') parent: #Morphic; target: Editor; description: 'When true, the text cursor will blink.' -------------------
is so much more "complicated" than
Editor class>>blinkingCursor <preference: 'Blinking Text Cursor' category: 'Morphic' description: 'When true, the text cursor will blink.' type: #Boolean> ^ BlinkingCursor ifNil: [ true ]
You're right, by itself it may not be "so much more complicated". But isn't this forgetting a few things? Like for example, that not only are you adding the extra method, but also an extra class and an extra package? This gets you from a single entity (the domain code) to four entities (the domain code, the builder method, class and package). In terms of both conceptual and interface simplicity that seems significant (and a dozen of messages in the builder all add to interface complexity).
BTW, I want to point out something important here. I'm not saying your approach is "bad". Good and bad, black and white, are not categories that I use for evaluating software design. I leave that to the people with overly simplified views on software development ;-) There are only different trade-offs for different goals. Your approach is perfectly reasonable for a given set of goals and trade-offs. If there is a need to have specific fine-grained control over the UI to particular preferences, I would choose precisely the same approach - make a package with views for the values that I want to modify. It's a perfectly fine approach for such a set of goals.
Moreover, "simplicity" isn't an absolute attribute of software. Simplicity is a tradeoff. It is often worthwhile to trade off simplicity, for example when adding valuable new features.
So my claim here is not about "good" and "bad". My claim is this:
- The approach in Squeak is measurably simpler than yours. It may not
fit your goals, you may need a different approach, that's quite possible. But there are numbers we can put on things to compare them and if we put the numbers on then Squeak's approach is simpler.
- Because of the difference in interface complexity, I expect Squeak's
approach will be easier to support in the long term. There's no proof for that, but I think the claim is valid, and I will watch the future developments in both Pharo and Squeak with interest.
- Your initial design choice of using a builder framework for
preferences implied the later complexity. Because the approach requires adding non-domain code to core classes it creates pressure to put this code elsewhere and to package that code separately. It's a valuable lesson about the impact of early design choices.
You prefer UI+domain mixing, we prefer UI separated from domain.
I'm missing something. What UI+domain mixing? There is no UI code in Squeak's preference tags. There is only domain code and a method tag for discovery of the preference. Only Pharo has UI (builder) code; there is no equivalent in Squeak's preference tags.
And yes, the SettingBrowser implementation could be improved. I know, but I'm happy because it can be removed or remade without any other consequence. And compare it to the PreferenceBrowser ...
I'm not certain what your point here is. I'm only talking about preference declaration, not about how the preference browser functions. PreferenceBrowser itself is reloadable in Squeak 4.1 and one of the packages that I customarily unload for creating smaller images, because I'm quite happy to set my preferences by sending message to objects directly :-)
Cheers,
- Andreas
squeak-dev@lists.squeakfoundation.org
-
Alain Plantec -
Andreas Raab -
Hannes Hirzel