Deprecation policy

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

Deprecation policy

Sean P. DeNigris
Administrator
I want to add a comment to #deprecated:on:in:

This is my understanding (it is implemented inconsistently in 1.4 update #14112):

For methods:
1. Have the method call deprecated:on:in: as its first step
  - the versionString should be e.g. 'Pharo1.4' (although I found #Pharo1.4, see the problem; and '1.4', those were mine, hee hee). Is it redundant to say 'PharoXxx'?
2. Move the method to protocol e.g. deprecated14 for Pharo 1.4

For classes:
1. Move to Category e.g. 'Deprecated14' for Pharo 1.4
2? Should #deprecated:on:in: be called from the methods? It's inconsistent in the image and seems unnecessary, except maybe for some class-side methods.

Is all this correct?

Thanks.
Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation policy

Sean P. DeNigris
Administrator
Are pre-1.3 deprecated methods purposely put into protocol *deprecated13?

For example:
String>>asDefaultDecodedString on: 2/13/2010 in: 1.1
PluggableTextMorph>>setTextColor: on: 8/17/2010 in: 1.2
SequencableCollection>>sortBy: on: 9/4/2010 in: 1.2
SystemDictionary>>hasSpecialSelector:ifTrueSetByte: on: 3/20/2010 in: 1.1
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation policy

Sean P. DeNigris
Administrator
In reply to this post by Sean P. DeNigris
Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August, 2011'. Does it matter?
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation policy

Stéphane Ducasse
In reply to this post by Sean P. DeNigris

On Aug 30, 2011, at 1:23 AM, Sean P. DeNigris wrote:

> I want to add a comment to #deprecated:on:in:
>
> This is my understanding (it is implemented inconsistently in 1.4 update
> #14112):
>
> For methods:
> 1. Have the method call deprecated:on:in: as its first step
>  - the versionString should be e.g. 'Pharo1.4' (although I found #Pharo1.4,
> see the problem; and '1.4', those were mine, hee hee). Is it redundant to
> say 'PharoXxx'?
> 2. Move the method to protocol e.g. deprecated14 for Pharo 1.4
>
this protocol could be an extension of the deprecatedXX package
but not necessarily. because sometimes we want to keep the method longer

> For classes:
> 1. Move to Category e.g. 'Deprecated14' for Pharo 1.4
> 2? Should #deprecated:on:in: be called from the methods? It's inconsistent
> in the image and seems unnecessary, except maybe for some class-side
> methods.

Yes because this is a lot of work and not convincing :)

>
> Is all this correct?
>
> Thanks.
> Sean
>
> --
> View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777647.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Deprecation policy

Marcus Denker-4
In reply to this post by Sean P. DeNigris

On Aug 30, 2011, at 1:44 AM, Sean P. DeNigris wrote:

> Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August,
> 2011'. Does it matter?

No

>
> --
> View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777671.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: Deprecation policy

Stéphane Ducasse
In reply to this post by Sean P. DeNigris

On Aug 30, 2011, at 1:43 AM, Sean P. DeNigris wrote:

> Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August,
> 2011'. Does it matter?

not really right now. but ok to live with it.
Now it would be good to have a refactoring to deprecate a method (but I had no time and know how to add one)
>
> --
> View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777671.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Deprecation policy

Marcus Denker-4
In reply to this post by Sean P. DeNigris

On Aug 30, 2011, at 1:35 AM, Sean P. DeNigris wrote:

> Are pre-1.3 deprecated methods purposely put into protocol *deprecated13?
>
> For example:
> String>>asDefaultDecodedString on: 2/13/2010 in: 1.1
> PluggableTextMorph>>setTextColor: on: 8/17/2010 in: 1.2
> SequencableCollection>>sortBy: on: 9/4/2010 in: 1.2
> SystemDictionary>>hasSpecialSelector:ifTrueSetByte: on: 3/20/2010 in: 1.1


Sometimes we move methods to keep them longer, somtimes methods get "lost"
from the package because of accidental re-categoration, and than moved to the
current deprecated package.

        Marcus

--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: Deprecation policy

Stéphane Ducasse
In reply to this post by Sean P. DeNigris
at least we should get this list studied and we decide.
we shoudl open a bug entry.

On Aug 30, 2011, at 1:34 AM, Sean P. DeNigris wrote:

> Are pre-1.3 deprecated methods purposely put into protocol *deprecated13?
>
> For example:
> String>>asDefaultDecodedString on: 2/13/2010 in: 1.1
> PluggableTextMorph>>setTextColor: on: 8/17/2010 in: 1.2
> SequencableCollection>>sortBy: on: 9/4/2010 in: 1.2
> SystemDictionary>>hasSpecialSelector:ifTrueSetByte: on: 3/20/2010 in: 1.1
>
> --
> View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777660.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Deprecation policy

csrabak
In reply to this post by Sean P. DeNigris
I think that if we could use for dates a Date object, in the future it could be easier to create scripts or tools to manage these deprecations.
my devaluated 0.0199999.... 

[]s
--
Cesar Rabak


Em 29/08/2011 20:43, Sean P. DeNigris < [hidden email] > escreveu:
Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August,
2011'. Does it matter?

--
View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777671.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.