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

> Well
> well well
> 
>>> Good but what is your point?
>> 
>> Compatibility and simplicity.
> 
> do you want to tie us with strings on the temple of compatibility? We do not 
> want that. 
> 
> We are sorry but we do not want to lose what we designed as it is what we 
> need/want, just because squeak has a 
> worse solution that you call compatible and simple. 

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

Reply via email to