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