Hi Gary -

Let me throw in one additional thought: I'm not sure how one would deal 
with migration in Alain's case (I don't know David's work; I'm assuming 
you misspoke, but if not please point me to it). One of the issues is 
that there are currently some 694 (!) references to Preferences in a 
3.10.2 image. There will be more in external code.

One of the advantages of using a pragma for the simple cases is that we 
can start the migration today, without having sorted out all the details 
for the next-gen preferences implementation. People who want their code 
to work both in Squeak and Pharo can start doing this as soon as have a 
reasonable implementation for both (which I am willing to provide). I 
also don't expect the migration to be quick as there will be discussion 
where certain preferences should live etc.

A drop-dead conversion of saying "the day we load the new preferences 
implementation all old code will be broken" just won't work. So having a 
way that we know will be forward-compatible strikes me as absolutely 
necessary for any migration process. This is what I meant when I was 
saying that I think having something that abstracts from the preference 
implementation is absolutely necessary before we can consider adopting 
an alternative.

Cheers,
   - Andreas

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