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