Yes, was Alain (sorry there...).

Any of the proposed strategies are, I think, in a "moving forward" sense.
Each approach doesn't deal with migration of the existing state of play, 
that is, I believe, taken for-granted as something that will be migrated at 
some point.

Either proposal has the "advantage" of moving forward, pragmas one way, or 
the other, or something entirely different. Let us get the best possible 
implementation of the concept of preferences sorted between us before even 
thinking of the migration.

Nothing is finalised yet, but, I'm not convinced by the pragmas-only 
approach.

Just as a "fun" expression... "when is a preference not a preference" (when 
it is a pragma seems the obvious answer to me).
Nothing wrong with using pragmas to identify things though, I feel.

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 2:19 AM
Subject: [squeak-dev] Re: [ANN] Preference pragmas


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