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.htmlAs 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.
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
