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