[squeak-dev] Re: [ANN] Preference pragmas

Gary Chambers gazzaguru2 at btinternet.com
Mon Mar 9 02:03:11 UTC 2009


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
> 




More information about the Squeak-dev mailing list