I have to say that devolving any technical discussion into "you think
this..." and "we think that..." is a very quick way to destroy any ability
to think critically in a technical discussion.  This isn't Andreas "liking"
anything, this is the result of having thought critically and objectively
about the issues.  Can we please act like engineers and scientists ought?
 Substantive comments below.

On Thu, Apr 29, 2010 at 3:21 AM, Alain Plantec <[email protected]>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"
>
> 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 ]
> -------------------
>

Well the former is executable and must be executable.  The latter is not
necessarily executable (but its good if it is, because one can locate the
code that processes the specification) .  So they're the same on that level.
 But the former can only be executable and isn't separated from the
processing code, whereas the latter is separated.  The former also only
works in context (aBuilder) whereas the latter stands alone, and this
ability to stand alone, as a specification, loosely coupled to the settings
maintennance system is one thing that makes it simpler.  It also clearly
states the default value which the former doesn't.  So I find the latter
significantly easier to understand, and given I understand the method
annotation system I find the mechanics not that much more complicated than
the former's.  We all understand perform: right?


> You prefer UI+domain mixing, we prefer UI separated from domain.
>

I see the opposite.  I see good separation in the latter example but I don't
see the separation in the former.  And BTW this is me trying to think
critically, trying to keep happy feet in both the Pharo and Squeak (and
eToys and Cuis and ....) camps, not trying to be tribal.  Apologies in
advance if expressing a contradictory view is taken as offensive.



> 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
>
>
best
Eliot


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

Reply via email to