Before removing the preference class, maybe you could rename it simply at the beginning. Alexandre On 28 May 2009, at 03:08, Alain Plantec wrote:
Hi all,
We have to make important decisions about squeak/pharo compatibility regarding the new setting package. The problem is that some packages (as Polymorph but also OB, ecompletion and certainly a lot of others) are included in pharo (aka pharo-dev) but are also used by squeak and the compatibility is now an issue because we plan to remove the Preferences class from Pharo. So, I'm looking for advices about that... Any feedback ?
Cheers Alain
From: Alain Plantec <alain.plantec@univ-brest.fr> Date: 27 May 2009 13:21:25 GMT-04:00 To: Gary Chambers <gazzaguru2@btinternet.com> Subject: Re: preferences refactoring Reply-To: alain.plantec@univ-brest.fr
Gary Chambers a écrit :
Hi Alain.
I guess I may have to fork the Pharo/Squeak specific areas. Not an easy job! yes, not really cool.
what about the following: I make the assumption that DiffMorph is using the browseWithPrettyPrint preference. For pharo, you can create a new package with a PolymorphSettings class:
---------------------- PolymorphSettings class>>browseWithPrettyPrint <setting> ^ BrowseWithPrettyPrint ifNil: [ BrowseWithPrettyPrint := (SettingManager newSetting: 'bla bla') ... ]
PolymorphSettings class>>initialize self browseWithPrettyPrint whenChangedSend: #prettyPrinting: to: DiffMorph ----------------------
For squeak you can also create a new package with a PolymorphPreferences class:
---------------------- PolymorphPreferences class>>initialize (Preferences preferenceAt: #browseWithPrettyPrint) ifNil:[ Preferences addPreference: #browseWithPrettyPrint categories: #(browsing) default: true balloonHelp: 'Enable, or ...'. (Preferences preferenceAt: browseWithPrettyPrint) changeInformee: self changeSelector: #browseWithPrettyPrintChanged. self browseWithPrettyPrintChanged]. PolymorphPreferences class>>browseWithPrettyPrintChanged DiffMorph prettyPrinting: Preferences browseWithPrettyPrint
----------------------
and as you pointed out, DiffMorph has also its own class variable for the preference.
DiffMorph class>>prettyPrinting: aBoolean PrettyPrinting := aBoolean
DiffMorph class>>prettyPrinting ^ PrettyPrinting
Thus, in Pharo PolymorphSettings is loaded and the DiffMorph class variable changes are handled via the setting. In Squeak, PolymorphPreferences is loaded and the DiffMorph class variable updating relies on the changeInformee hook.
a little bit ugly but I guess this is the price to pay for compatibility.
what do you think ?
Cheers Alain
To start I'll refactor Polymorph to use class side accessors for any use of preferences. That way Squeak can delegate to Preferences whilst Pharo can use the pragma based settings.
E.g. DiffMorph>>setText can do
self class colorWhenPrettyPrinting value
In Squeak:
DiffMorph class>>colorWhenPrettyPrinting ^Preferences colorWhenPrettyPrinting
In Pharo:
DiffMorph class>>colorWhenPrettyPrinting ^ColorWhenPrettyPrinting ifNil: [ ColorWhenPrettyPrinting := (SettingManager newSetting: 'Color pretty print') default: false]
Regards, Gary
----- Original Message ----- From: "Alain Plantec" <alain.plantec@univ-brest.fr
To: "Gary Chambers" <gazzaguru2@btinternet.com> Sent: Friday, May 22, 2009 3:56 PM Subject: preferences refactoring
Hi Gary, During the migration from old preferences to the new setting framework, some methods I'm changing can be from Polymorph packages. I just like to know if I have to send to you polymorph specific parts ? or what is the rule ? As an example, DiffMorph>>setText will be touched by the removal of the #colorWhenPrettyPrinting preference. Do I have to send to you a Polymorph specific part ? Thanks Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.