Re: [Pharo-project] deprecated: in Deprecated14
On Nov 25, 2011, at 11:53 AM, Pavel Krivanek wrote:
Hi,
I would like to ask if the current solution where the method Object>>#deprecated: is placed in the package Deprecated14, is good.
I think the idea was to deprecate deprecated: so people use the one with more infos... (deprecated:on:in:) But for small external projects, deprecated: is just fine and there are users. So I suggest we just move it out of the deprecated package and have it as a simple to use version of deprecation tagging.
For images where this package is not present (e.g. Pharo-Kernel) we got unimplemented call and possible DNU. The method #deprecated:on:in: is in the kernel.
Of course if you do not have deprecated code in the image then call of it should raise error. However some external packages (and some internal packages like Zinc) do not have deprecated code in separate package and do use #deprecated: for deprecation warnings.
Because #deprecated: is bound to Pharo version, I think it would be better solution to have a message named pharoDeprecated: that will be called from Pharo packages that will be placed in Deprecated14 package and then have #deprecated: message placed in the kernel that will be used by external packages.
Cheers, -- Pavel
-- Marcus Denker -- http://marcusdenker.de
Ok for me -- Pavel 25.11.2011 v 16:15, Marcus Denker <marcus.denker@inria.fr>:
On Nov 25, 2011, at 11:53 AM, Pavel Krivanek wrote:
Hi,
I would like to ask if the current solution where the method Object>>#deprecated: is placed in the package Deprecated14, is good.
I think the idea was to deprecate deprecated: so people use the one with more infos... (deprecated:on:in:)
But for small external projects, deprecated: is just fine and there are users. So I suggest we just move it out of the deprecated package and have it as a simple to use version of deprecation tagging.
For images where this package is not present (e.g. Pharo-Kernel) we got unimplemented call and possible DNU. The method #deprecated:on:in: is in the kernel.
Of course if you do not have deprecated code in the image then call of it should raise error. However some external packages (and some internal packages like Zinc) do not have deprecated code in separate package and do use #deprecated: for deprecation warnings.
Because #deprecated: is bound to Pharo version, I think it would be better solution to have a message named pharoDeprecated: that will be called from Pharo packages that will be placed in Deprecated14 package and then have #deprecated: message placed in the kernel that will be used by external packages.
Cheers, -- Pavel
-- Marcus Denker -- http://marcusdenker.de
Marcus Denker-4 wrote
I think the idea was to deprecate deprecated: so people use the one with more infos... (deprecated:on:in:)
But for small external projects, deprecated: is just fine and there are users. So I suggest we just move it out of the deprecated package and have it as a simple to use version of deprecation tagging.
It was quite a bit of work to clean the system of calls to #deprecated: http://code.google.com/p/pharo/issues/detail?id=4718 If it's an important feature of other projects (I don't see the value over the more informative version; who has a use case?), maybe the best thing is for it to be loadable but not included by default? If it's left in the image, I'm sure habit and inertia will have people continue to use it in the core image, which is not what we want. Sean -- View this message in context: http://forum.world.st/deprecated-in-Deprecated14-tp4107546p4108889.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
+ 1 Given a date and a version is a nice way to educate people to traceability.
Marcus Denker-4 wrote
I think the idea was to deprecate deprecated: so people use the one with more infos... (deprecated:on:in:)
But for small external projects, deprecated: is just fine and there are users. So I suggest we just move it out of the deprecated package and have it as a simple to use version of deprecation tagging.
It was quite a bit of work to clean the system of calls to #deprecated: http://code.google.com/p/pharo/issues/detail?id=4718
If it's an important feature of other projects (I don't see the value over the more informative version; who has a use case?), maybe the best thing is for it to be loadable but not included by default? If it's left in the image, I'm sure habit and inertia will have people continue to use it in the core image, which is not what we want.
Sean
-- View this message in context: http://forum.world.st/deprecated-in-Deprecated14-tp4107546p4108889.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (4)
-
Marcus Denker -
Pavel Krivanek -
Sean P. DeNigris -
Stéphane Ducasse