Michael Rueger wrote:
> Looking at your version I see you made some slightly different design 
> choices than in the design that has been in design discussion and worked 
> on in the last couple of weeks on the Pharo list.
> 
> Can you elaborate what motivated the different design? Meaning what 
> parts of the Pharo version could be made better? Or, sorry for basically 
> asking the same thing three times, what would it take to adopt the Pharo 
> version for Squeak?

Good question. I'm not (yet?) in a position to answer it. But it would 
be good if you could point people to the code so they can look at it. 
And if you would like to get it into 3.11 have please follow the process 
described here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134095.html

As for my variant, I wouldn't actually call it much of design ;-) More 
like the simplest thing that I could possibly come up with and that 
would work in the time frame that I had myself allowed to do it. If I 
would have allowed myself a bit more time on it I would have done things 
differently: I was thinking about exposing the actual class variable as 
the preference object. In other words, the spec would've looked like:

   <preference: #ClassVarName
      label: 'Preference label'
      category: 'PrefCategory'
      balloonHelp: 'Your help goes here'
      type: #TypeName>

and it would result in Preferences looking up the class var and using it 
directly. The reason I like this better is that it allows the preference 
to be implicitly synchronized. Since preference and class variable are 
the same object, they cannot get out of sync (the version I posted 
allows setting the value without updating the preference).

Exposing the class variable as preference also allows some interesting 
uses like project- (or process-) local preferences simply by using a 
different type of variable binding. I have recently been playing with 
ProjectLocalBindings which redirect access to Project current to allow 
for different values of our old friends Display and Sensor and it has 
proven very fruitful. Preferences would be another very natural 
application for these bindings. But obviously, this is more work (and it 
didn't look pretty when I checked PreferenceValue and friends) so I just 
wasn't up for it so I choose the easy way out ;-)

In any case, I'm not wed to my implementation. It's simple and 
non-intrusive (which is good), it doesn't expose any of the internals 
like PreferenceValue, PreferenceViewRegistry etc (which is good) but 
other than that I have zero attachment to it. If there is a better 
implementation that's out there let's just use that. The one desire I 
would have for that implementation is that it allows taking out all the 
preferences stuff for systems which don't provide a UI for it. I would 
like to be able to add preferences in this form to some fairly low level 
parts of the system and tying it into the presentation layer would be a 
mistake for that.

Cheers,
   - Andreas

PS. I'm only posting this to Squeak-dev since I have a distinct feeling 
that my comments wouldn't be very welcome on the Pharo list. Please feel 
free to forward it and correct me if I am mistaken.