[Pharo-project] <deprecated> annotation?
Hello, i know that we're already having #deprecated: , #deprecated: on: in: etc but one thing what i think useful about annotations that it is a way to indicate that method is deprecated without showing a warning. The problem with using messages, that if you deprecate something which used quite often by code, you will be spammed with deprecation warnings all the time. So, i think that in addition to messages, we can use these annotations, to indicate deprecated methods, in places where showing warning(s) are not feasible (for instance you cannot deprecate Deprecation>>showWarning, because it will lead to infinite recurtion) There could be variations in same way as with messages: <deprecated> <deprecated: '...' on: '..' in: '..'> etc. What you think? -- Best regards, Igor Stasenko AKA sig.
Currently i run upon this situation, when annotation is the only possible choice: SmalltalkImage>>vmParameterAt: parameterIndex "This method is deprecated. We're not putting a #deprecated: message here, because then it will produce a lot of warnings" <deprecated> ^ self vm parameterAt: parameterIndex -- Best regards, Igor Stasenko AKA sig.
Ok you won! But we want a nice comment in all deprecated methods :) Stef On Aug 16, 2011, at 7:55 PM, Igor Stasenko wrote:
Currently i run upon this situation, when annotation is the only possible choice:
SmalltalkImage>>vmParameterAt: parameterIndex "This method is deprecated.
We're not putting a #deprecated: message here, because then it will produce a lot of warnings"
<deprecated>
^ self vm parameterAt: parameterIndex
-- Best regards, Igor Stasenko AKA sig.
On 16.08.2011 19:51, Igor Stasenko wrote:
Hello,
i know that we're already having #deprecated: , #deprecated: on: in: etc
but one thing what i think useful about annotations that it is a way to indicate that method is deprecated without showing a warning.
The problem with using messages, that if you deprecate something which used quite often by code, you will be spammed with deprecation warnings all the time.
So, i think that in addition to messages, we can use these annotations, to indicate deprecated methods, in places where showing warning(s) are not feasible (for instance you cannot deprecate Deprecation>>showWarning, because it will lead to infinite recurtion)
There could be variations in same way as with messages:
<deprecated> <deprecated: '...' on: '..' in: '..'>
etc.
What you think?
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends? Yeah you could write tools support but we both know this isn't gonna happen. Cheers Philippe
What you think?
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends?
+1, such an annotation is totally counterproductive. Lukas -- Lukas Renggli www.lukas-renggli.ch
On 17 August 2011 14:23, Lukas Renggli <renggli@gmail.com> wrote:
What you think?
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends?
+1, such an annotation is totally counterproductive.
Provide an alternative. Imagine that we're want to deprecate Array>>at: what is possible solution? Because we need to have some way to deal with deprecation things like that, not only stuff which used sparingly.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Best regards, Igor Stasenko AKA sig.
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends?
+1, such an annotation is totally counterproductive.
Provide an alternative. Imagine that we're want to deprecate Array>>at:
Disable the deprecateded notifications in the system settings. Like this you acknoledge that you use outdated code; and if this gets too annoying you might want to actually fix it. Ideally the deprecated notification debugger could allow you to disable further warnings. However deprecated warnings should always be turned on in downloaded images, otherwise we can as well remove them. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Aug 17, 2011, at 2:40 34PM, Lukas Renggli wrote:
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends?
+1, such an annotation is totally counterproductive.
Provide an alternative. Imagine that we're want to deprecate Array>>at:
Disable the deprecateded notifications in the system settings. Like this you acknoledge that you use outdated code; and if this gets too annoying you might want to actually fix it.
Ideally the deprecated notification debugger could allow you to disable further warnings. However deprecated warnings should always be turned on in downloaded images, otherwise we can as well remove them.
Lukas
+1000 to what Lukas and Phillippe are saying. Always show deprecation warnings for a call site at least once. The whole point of deprecations vanishes if you are not made aware of them at all... If the deprecated method stored callsites in some dictionary, then skipped raising debuggers if already in the dict, that'd be swell. Didn't Alain Plaintec already make a nice GUI for browsing such triggered deprecations, or am I imagining things? IE. I think tool support is much better than a pragma. In fact, for deprecating commonly used methods I feel it is crucial. Until present, may I suggest just not deprecating such methods? I don't see any other way that will not inevitably lead to lots of swearing by users. Cheers, Henry
Hi Lukas, Igor 2011/8/17 Lukas Renggli <renggli@gmail.com>:
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends?
+1, such an annotation is totally counterproductive.
Provide an alternative. Imagine that we're want to deprecate Array>>at:
Disable the deprecateded notifications in the system settings. Like this you acknoledge that you use outdated code; and if this gets too annoying you might want to actually fix it.
What I don't like of disabling deprecations is that is black or white. You get deprecations or you don't get at all. My view is that deprecations are context dependent, I want to disable them: -For this package -For this class and -For this execution context (or "session") -Always Why? Because I'm working in other parts of the code and now I don't want to care deprecations in an unrelated package/class, but I know later I'd like to see them. Hernán
On 17.08.2011 16:05, Hernán Morales Durand wrote:
Hi Lukas, Igor
2011/8/17 Lukas Renggli <renggli@gmail.com>:
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends?
+1, such an annotation is totally counterproductive.
Provide an alternative. Imagine that we're want to deprecate Array>>at:
Disable the deprecateded notifications in the system settings. Like this you acknoledge that you use outdated code; and if this gets too annoying you might want to actually fix it.
What I don't like of disabling deprecations is that is black or white. You get deprecations or you don't get at all. My view is that deprecations are context dependent, I want to disable them: -For this package -For this class
That's a good point. Cheers Philippe
On 17 August 2011 14:14, Philippe Marschall <kustos@gmx.net> wrote:
On 16.08.2011 19:51, Igor Stasenko wrote:
Hello,
i know that we're already having #deprecated: , #deprecated: on: in: etc
but one thing what i think useful about annotations that it is a way to indicate that method is deprecated without showing a warning.
The problem with using messages, that if you deprecate something which used quite often by code, you will be spammed with deprecation warnings all the time.
So, Â i think that in addition to messages, we can use these annotations, to indicate deprecated methods, in places where showing warning(s) are not feasible (for instance you cannot deprecate Deprecation>>showWarning, because it will lead to infinite recurtion)
There could be variations in same way as with messages:
<deprecated> <deprecated: '...' on: '..' in: '..'>
etc.
What you think?
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning.
Yes. You get an error instead of warning :)
You are you supposed to check for deprecated methods? Debug each and every one of your message sends?
Yeah you could write tools support but we both know this isn't gonna happen.
I understand your concerns. I don't like this too. But what choice you have if you have to deprecate something which used a lot? If you put a message there, you will get an image, which will show you warnings every time you doing something. This will piss off users up to the point that for comfortable work, they won't have other choice but to disable deprecation warnings, which means that at the end we will have same issue: once you disable it, you cannot see anymore whether your code using deprecated stuff or not.
Cheers Philippe
-- Best regards, Igor Stasenko AKA sig.
On 17.08.2011 14:24, Igor Stasenko wrote:
On 17 August 2011 14:14, Philippe Marschall <kustos@gmx.net> wrote:
On 16.08.2011 19:51, Igor Stasenko wrote:
Hello,
i know that we're already having #deprecated: , #deprecated: on: in: etc
but one thing what i think useful about annotations that it is a way to indicate that method is deprecated without showing a warning.
The problem with using messages, that if you deprecate something which used quite often by code, you will be spammed with deprecation warnings all the time.
So, i think that in addition to messages, we can use these annotations, to indicate deprecated methods, in places where showing warning(s) are not feasible (for instance you cannot deprecate Deprecation>>showWarning, because it will lead to infinite recurtion)
There could be variations in same way as with messages:
<deprecated> <deprecated: '...' on: '..' in: '..'>
etc.
What you think?
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning.
Yes. You get an error instead of warning :)
Right, I get an MNU. If this is your "solution" then you don't need deprecation at all, you can just straight out remove the method. Which I'm not against, don't get be wrong. But in this case I really don't see the point in the pragma.
You are you supposed to check for deprecated methods? Debug each and every one of your message sends?
Yeah you could write tools support but we both know this isn't gonna happen.
I understand your concerns. I don't like this too. But what choice you have if you have to deprecate something which used a lot? If you put a message there, you will get an image, which will show you warnings every time you doing something. This will piss off users up to the point that for comfortable work, they won't have other choice but to disable deprecation warnings,
Been like this for years.
which means that at the end we will have same issue: once you disable it, you cannot see anymore whether your code using deprecated stuff or not.
I don't do that because I have to either fix that code or inform some other person that they need to fix their code. Cheers Philippe
On Wed, 17 Aug 2011, Philippe Marschall wrote:
On 16.08.2011 19:51, Igor Stasenko wrote:
Hello,
i know that we're already having #deprecated: , #deprecated: on: in: etc
but one thing what i think useful about annotations that it is a way to indicate that method is deprecated without showing a warning.
The problem with using messages, that if you deprecate something which used quite often by code, you will be spammed with deprecation warnings all the time.
So, i think that in addition to messages, we can use these annotations, to indicate deprecated methods, in places where showing warning(s) are not feasible (for instance you cannot deprecate Deprecation>>showWarning, because it will lead to infinite recurtion)
There could be variations in same way as with messages:
<deprecated> <deprecated: '...' on: '..' in: '..'>
etc.
What you think?
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends?
Yeah you could write tools support but we both know this isn't gonna happen.
What about using "soft deprecation". If would raise an exception which would have no default action, but from the TestRunner (or other tools) you'd be noticed that your code relies on deprecated methods. So if your code has good test coverage, then you'll know that you have to update your code. For example: foo self softDeprecated: 'This method shouldn't be used anymore. Use #bar instead." ... Levente
Cheers Philippe
On 17 August 2011 14:26, Levente Uzonyi <leves@elte.hu> wrote:
On Wed, 17 Aug 2011, Philippe Marschall wrote:
On 16.08.2011 19:51, Igor Stasenko wrote:
Hello,
i know that we're already having #deprecated: , #deprecated: on: in: etc
but one thing what i think useful about annotations that it is a way to indicate that method is deprecated without showing a warning.
The problem with using messages, that if you deprecate something which used quite often by code, you will be spammed with deprecation warnings all the time.
So, Â i think that in addition to messages, we can use these annotations, to indicate deprecated methods, in places where showing warning(s) are not feasible (for instance you cannot deprecate Deprecation>>showWarning, because it will lead to infinite recurtion)
There could be variations in same way as with messages:
<deprecated> <deprecated: '...' on: '..' in: '..'>
etc.
What you think?
How would that help anybody to find out whether they are relying on deprecated methods? This seems like a big step backwards form a user point of view. Suddenly a method is gone and you didn't get a warning. You are you supposed to check for deprecated methods? Debug each and every one of your message sends?
Yeah you could write tools support but we both know this isn't gonna happen.
What about using "soft deprecation". If would raise an exception which would have no default action, but from the TestRunner (or other tools) you'd be noticed that your code relies on deprecated methods. So if your code has good test coverage, then you'll know that you have to update your code. For example:
foo
    self softDeprecated: 'This method shouldn't be used anymore. Use #bar instead."     ...
+1 this seems like a nice way to solve the problem. So, we can add a Deprecation subclass, say SoftDeprecation and then modify test runner to catch all deprecations while running tests. Because right now we don't have a way to deprecate stuff, which is used often: things like browser protocol, system navigation, SmalltalkImage, Morphic, Canvas etc etc.. -- Best regards, Igor Stasenko AKA sig.
participants (7)
-
Henrik Johansen -
Hernán Morales Durand -
Igor Stasenko -
Levente Uzonyi -
Lukas Renggli -
Philippe Marschall -
Stéphane Ducasse