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
--- Begin Message ---
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"
<[email protected]>
To: "Gary Chambers" <[email protected]>
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
--- End Message ---
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
