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