[Pharo-project] Deprecation policy
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 -- View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777647.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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.
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.
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.
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.
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.
participants (3)
-
csrabak＠bol.com.br -
Sean P. DeNigris -
Stéphane Ducasse