On 09.03.2009, at 03:03, Gary Chambers wrote:
>
> Indeed, I see the point you are making.
>
> I just have a "feeling" that making this as restrictive will mean
> we'll be having the same discussion soon again!
> Always tricky to get any decisions made without a solution that
> satisfies all viewpoints...
>
> What I will say in favour of David's work is that it is extensible
> and, like your approach, deals with the localisation vs. general
> kackness that is the current situation.
Now while even urbandictionary.com does not know the term "kackness" I
agree that I'd value a preference system that allows localization much
higher than one that does not.
- Bert -
> I could live with "extension methods" on a Preference class, I think
> (probably)... just a bit nasty with it dynamically compiling code
> etc.
>
> We should all discuss some more, perhaps, to get the best solution
> we can, given that this is quite fundamental (Squeakers are *used*
> to having choice...).
>
> Regards, Gary
>
> ----- Original Message ----- From: "Andreas Raab"
> <
[hidden email]>
> To: "The general-purpose Squeak developers list" <
[hidden email]
> >
> Sent: Monday, March 09, 2009 1:40 AM
> Subject: [squeak-dev] Re: [ANN] Preference pragmas
>
>
>> Gary Chambers wrote:
>>> The use of "extended" pragmas is interesting, although, to my mind
>>> it doesn't address the problem/benefit of complex preference
>>> values (non-literal).
>>>
>>> As for the value guard, good, but the ranges etc. are not exposed
>>> to potential tools (would be nice to NOT be able to input 99, for
>>> instance).
>>>
>>> I think, at this stage, I still believe the "modelling of a
>>> preference" approach more flexible.
>>
>> I agree with this statement. It is more flexible to model the
>> preference explicitly. And I am not proposing to make the
>> preference pragma achieve that level of flexibility. What I'm
>> proposing is to keep the pragma as simple as possible, use it in
>> the cases where it's useful and model the preference explicitly if
>> more flexibility is required.
>>
>> This way, the dependency on a specific preference implementation
>> will be greatly reduced and for many uses preferences can be added
>> to low-level code without introducing a dependency on the
>> implementation. Plus it makes shipping preferences between
>> implementations reasonably easy; much of the code that would
>> otherwise be incompatible between Pharo and Squeak (and beyond, for
>> example VW) can be compatible.
>>
>> Cheers,
>> - Andreas
>
>
Locked
