On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote:

But I think we should add back a Preferences class for allowing to load old code. (it's referenced
in the class side initialize in old code often...)

The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses Preferences.
So....we really need help of the external package maintainers to update them. And I am not sure how easy is that.

What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preference

class return true or false for that preference. That should be 90% of all usages, I guess..

We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.

compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...).

I mean...is there a mapping between each previous preference a the new ones?

In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity.