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 |
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 |
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 |
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 > 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. > |
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 |
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. > |
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 |
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. > |
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. |
Free forum by Nabble | Edit this page |