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

Nicolas

2009/5/28 Alain Plantec <[email protected]>:
> 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 <[email protected]>
>>> Date: 27 May 2009 13:21:25 GMT-04:00
>>> To: Gary Chambers <[email protected]>
>>> Subject: Re: preferences refactoring
>>> Reply-To: [email protected]
>>>
>>>
>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

Reply via email to