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"  
> <andreas.raab at gmx.de>
> To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org 
> >
> 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
>
>