[Squeak-dev] World Menu Registry

> On 4/28/2010 11:40 AM, Nicolas Cellier wrote:
>>
>> It's a question of tools for sure, with a textual representation we
>> can manage versions and exchange objects more easily.
>> But it's also a question of quality process. Selling the object
>> without the building process is like we lost the recipe.
>
> I like this, it's a great quote. Did you come up with it? I'd like to
> attribute it properly.
>

> Cheers,
>  - Andreas
>
>> Textual representation is limitating (a good example is a programmed
>> icon versus an artistic one), but easier to manage and reproduce.
>>
>> When I worked with VW, I used objects a lot at the beginning, but when
>> bored porting from an image to the other (the problem being how to be
>> sure I did not forget an object), I cut my wings and fell back to
>> text.
>>
>> Nicolas
>>
>>
>
>
>

> 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 ]
> -------------------

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