SLICE-PreferencesMigrationPart5

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

SLICE-PreferencesMigrationPart5

Alain Plantec-4
------------------
SLICE-PreferencesMigrationPart5 is in InBox

* remove projectPreferenceFlagDictionary inst var from Project
* migrate "docking bars" group
* migrate "fileout" group
* remove all  remaining deprecated popup (hope it makes OB using ok)
------------------

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: SLICE-PreferencesMigrationPart5

Henrik Sperre Johansen
A practice I've seen, and found useful in the past, is replacing the deprecated method body with the corresponding non-deprecated method call.
This makes proceeding warnings work, and if you turn off warnings, the calls doesn't stop behaving correctly before you replace them.

Could this be done, or are the semantics to new settings too different?

Cheers,
Henry
 
On Dec 7, 2009, at 3:41 12PM, Alain Plantec wrote:

> ------------------
> SLICE-PreferencesMigrationPart5 is in InBox
>
> * remove projectPreferenceFlagDictionary inst var from Project
> * migrate "docking bars" group
> * migrate "fileout" group
> * remove all  remaining deprecated popup (hope it makes OB using ok)
> ------------------
>
> 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: SLICE-PreferencesMigrationPart5

Alain Plantec-4
Hi Henrik,

For now, I've only replaced the deprecated method body with the corresponding
non-deprecated one. This should make pharo run as requested without any annoying
popup.
All these methods are localized in the Preferences class. It will be very easy
to retrieve them and insert a "self deprecated: 'bla bla bla'".
Thanks for your comments
Cheers
Alain

Selon Henrik Johansen <[hidden email]>:

> A practice I've seen, and found useful in the past, is replacing the
> deprecated method body with the corresponding non-deprecated method call.
> This makes proceeding warnings work, and if you turn off warnings, the calls
> doesn't stop behaving correctly before you replace them.
>
> Could this be done, or are the semantics to new settings too different?
>
> Cheers,
> Henry
>
> On Dec 7, 2009, at 3:41 12PM, Alain Plantec wrote:
>
> > ------------------
> > SLICE-PreferencesMigrationPart5 is in InBox
> >
> > * remove projectPreferenceFlagDictionary inst var from Project
> > * migrate "docking bars" group
> > * migrate "fileout" group
> > * remove all  remaining deprecated popup (hope it makes OB using ok)
> > ------------------
> >
> > 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: SLICE-PreferencesMigrationPart5

Stéphane Ducasse
Yes thanks.
Because we did what henrik suggested in the past.

Stef

On Dec 7, 2009, at 5:17 PM, [hidden email] wrote:

> Hi Henrik,
>
> For now, I've only replaced the deprecated method body with the corresponding
> non-deprecated one. This should make pharo run as requested without any annoying
> popup.
> All these methods are localized in the Preferences class. It will be very easy
> to retrieve them and insert a "self deprecated: 'bla bla bla'".
> Thanks for your comments
> Cheers
> Alain
>
> Selon Henrik Johansen <[hidden email]>:
>
>> A practice I've seen, and found useful in the past, is replacing the
>> deprecated method body with the corresponding non-deprecated method call.
>> This makes proceeding warnings work, and if you turn off warnings, the calls
>> doesn't stop behaving correctly before you replace them.
>>
>> Could this be done, or are the semantics to new settings too different?
>>
>> Cheers,
>> Henry
>>
>> On Dec 7, 2009, at 3:41 12PM, Alain Plantec wrote:
>>
>>> ------------------
>>> SLICE-PreferencesMigrationPart5 is in InBox
>>>
>>> * remove projectPreferenceFlagDictionary inst var from Project
>>> * migrate "docking bars" group
>>> * migrate "fileout" group
>>> * remove all  remaining deprecated popup (hope it makes OB using ok)
>>> ------------------
>>>
>>> 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