Re: [squeak-dev] Re: Menu Registries

+1

So now we will be the guys that do not want to be backward compatible, but this is on the web page
of pharo so nothing really new to me :)


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

On Apr 29, 2010, at 11:30 06AM, Stéphane Ducasse wrote:

It's not a question of one vs. the other, really.
The cs doesn't change the Settings implementation, it simply adds support for also discovering settings defined in the pragma style used by Squeak.
The downside is you'd have two ways to define settings.
The upside is the
>
>> I'm still interested in compatibility though, and as a consequence, I think we should agree on some basics. It's unlikely that anyone is going to implement the entire Pharo Settings framework in Squeak, so instead I'm giving you a trivial implementation of Squeak's preference annotation, along the way making a point about simplicity.
>
> yes but what can we do with it?
> Since it does not fit our needs.

It does not fit all the needs, no.
 - Sub-categories: Not impossible, but still; not supported.
-  Advanced value types: Specific strings like passwords, filenames, radio-button type prefs, integers with ranges, etc.
- Precondition: etc. are not supported.

In Pharo, there are
- 86 Settings (if I counted correctly, there could be some preconditional ones I didn't see as well).
- 23 Could be implemented Squeak-pragma style currently.
- 63 if sub-categories were supported.
The remaining 23 are split:  
        - chooses fonts (8)
        - conditional. (7)
        - multiple choice prefs whose possible values which can't be linked directly to type: by the builder (5)
        - have ranges to their possible values (4)
        - Chooses files (1)
        - Chooses password (1).

So no, the pragma/annotation don't fit our needs exactly. (For that matter, neither does it fit the needs of all preferences in Squeak)
If support for sub-categories was added, a lot of them could be written in the simpler squeak style though, with no loss of functionality.

IMO, providing support for both (if a way to specify sub-categories were decided upon) would match up well with the mantra: 'Make the common things easy; make the hard things possible'.

Cheers,
Henry

PS.
Multival could be supported in squeak with a type: #Choice or something, and an additional pragma somewhat like:
<preferenceChoiceFor: 'UI Theme'
                        label: 'Aqua 2'>


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

On Apr 29, 2010, at 12:46 17PM, Stéphane Ducasse wrote:

> +1
>
> So now we will be the guys that do not want to be backward compatible

Can't really claim that when neither approach is used in any existing released images ;)

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Henrik Johansen a écrit :
> On Apr 29, 2010, at 11:30 06AM, Stéphane Ducasse wrote:
>
> It's not a question of one vs. the other, really.
> The cs doesn't change the Settings implementation, it simply adds support for also discovering settings defined in the pragma style used by Squeak.
> The downside is you'd have two ways to define settings.
> The upside is the
>  
the upside is ... :)
well, I will have a look at the cs.
I would prefer that this changes do not introduce any
overwriting so that it can be loaded separately as a compatibility package.
so, i will investigate the changes needed for the settingbrowser.
is that ok like that ?
Cheers
Alain


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

On Apr 29, 2010, at 1:44 29PM, Alain Plantec wrote:

It needs a way to register new valid preference pragmas, and setting generators for such pragmas.
May I suggest... using pragmas? ;P

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Ok I see and I like your analysis.
This is much more positive energy :)
so what we could do is to integrate the code of andreas but write in big that we should not use it internally.
Tell me if I interpreted well your message :)

Stef

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

Yes sounds good.
Prove that 3 methods are enough because we are cool :)



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

Henrik Johansen a écrit :
> It needs a way to register new valid preference pragmas, and setting generators for such pragmas.
> May I suggest... using pragmas? ;P
>  
:)
I've checked and only two methods has to be adapted and one added in Pharo.
Then a compatibility package can be implemented for Squeak.
This package is optional and could be available for pharo-dev.
I will provide it soon.
Alain

> Cheers,
> Henry
>  


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

excellent!

On Apr 29, 2010, at 4:16 PM, Alain Plantec wrote:


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

Alain Plantec a écrit : The SqueakPreferences package is attached.
Henrik, can you check and put it somewhere for pharo-dev ?

For now, It only contains the following method:
----------------
SettingTreeBuilder>>preference: prefName category: category description:
description type: type
    <settingPragmaProcessor>
    "Process a Squeak preference pragma"
....
----------------
It is tagged by the #settingPragmaProcessor pragma which is used by the
builder
when a SettingBrowser is opened in order to retrieve current settings
keywords.

For Pharo settings, the following is implemented
----------------
SettingTreeBuilder>>systemsettings
    <settingPragmaProcessor>
    "Process a <systemsettings> pragma"
    currentPragma methodClass theNonMetaClass perform: currentPragma
selector with: self.
----------------

So, if Squeak makes use of a new pragma, the only thing to do is to add a
similar method in the SqueakPreferences package and tag it with a
#settingPragmaProcessor pragma.

thanks to Andreas for its cs, I've removed one method and changed
another one.

Cheers
Alain


>
>> Cheers,
>> Henry
>>  
>
>


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

http://code.google.com/p/pharo/issues/detail?id=2370

Alain Plantec a écrit :

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

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

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.



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

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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

Thanks!
I'll make sure to look at it when I get home.

Cheers,
Henry

Den 29. apr. 2010 kl. 19.26 skrev Alain Plantec <[hidden email]>:

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

Yes this is clear we got that discussion long time ago and we are aware of the pros and the cons. At least as a language designer expert this is obvious to me.
Now I do not want to argue again. The goal of setting is to have settings totally out of the code and only make sense in presence of an interpreter of them.
So...

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

Yes now the key dimension is whether your vocabulary is fixed or not.
When you have a fixed vocabulary then this is clear that the declarative syntax is the winner and the other one does not make sense.
But for preferences it does not work. or you should have a much more lengthly key and interpret the arguments.


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

I will not add more. I think that we should favor declarative syntax as much as we can but not more.

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

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/

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

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