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