[Fwd: Re: preferences refactoring]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Fwd: Re: preferences refactoring]

Alain Plantec-4
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

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"
> <[hidden email]>
> To: "Gary Chambers" <[hidden email]>
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: preferences refactoring]

Stéphane Ducasse
Ideally I would like to have pharo and squeak versions separated (may  
be the packages should have a OB-Squeak and OB-Pharo).
else we will never make real progress.
Stef

> 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 <[hidden email]>
> Date: May 27, 2009 7:21:25 PM CEDT
> To: Gary Chambers <[hidden email]>
> Subject: Re: preferences refactoring
> Reply-To: [hidden email]
>
>
> 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" <[hidden email]
>> >
>> To: "Gary Chambers" <[hidden email]>
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: preferences refactoring]

Alexandre Bergel
In reply to this post by Alain Plantec-4
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 <[hidden email]>
> Date: 27 May 2009 13:21:25 GMT-04:00
> To: Gary Chambers <[hidden email]>
> Subject: Re: preferences refactoring
> Reply-To: [hidden email]
>
>
> 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" <[hidden email]
>> >
>> To: "Gary Chambers" <[hidden email]>
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: preferences refactoring]

Alain Plantec-4
Alexandre Bergel a écrit :
> Before removing the preference class, maybe you could rename it simply
> at the beginning.
Hi Alexandre,
yes, we will do it with care.
Anyway we are far from being ready to remove it :(.
Before we remove it, we have to make sure that all client classes from
pharo are re-factored
such that they don't need it anymore.
Cheers
Alain

>
> 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 <[hidden email]>
>> Date: 27 May 2009 13:21:25 GMT-04:00
>> To: Gary Chambers <[hidden email]>
>> Subject: Re: preferences refactoring
>> Reply-To: [hidden email]
>>
>>
>> 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"
>>> <[hidden email]>
>>> To: "Gary Chambers" <[hidden email]>
>>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: preferences refactoring]

Nicolas Cellier
Isn't there any possibility to include a compatibility layer ?

Nicolas

2009/5/28 Alain Plantec <[hidden email]>:

> Alexandre Bergel a écrit :
>> Before removing the preference class, maybe you could rename it simply
>> at the beginning.
> Hi Alexandre,
> yes, we will do it with care.
> Anyway we are far from being ready to remove it :(.
> Before we remove it, we have to make sure that all client classes from
> pharo are re-factored
> such that they don't need it anymore.
> Cheers
> Alain
>>
>> 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 <[hidden email]>
>>> Date: 27 May 2009 13:21:25 GMT-04:00
>>> To: Gary Chambers <[hidden email]>
>>> Subject: Re: preferences refactoring
>>> Reply-To: [hidden email]
>>>
>>>
>>> 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"
>>>> <[hidden email]>
>>>> To: "Gary Chambers" <[hidden email]>
>>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project