https://kotlinlang.org logo
Join Slack
Powered by
Shouldn't a `@Deprecated` class have all of its me...
# announcements
o
Shouldn't a 
@Deprecated
class have all of its method automatically marked as deprecated?
đźš« 4
In what case does it make sense that a method isn't deprecated while its class is deprecated?
d
In the same way that marking a class as private doesn't mean all of it's methods should be automatically marked as private.
o
Whether a method is private or not does make a difference for code in that same file. If a method is marked as private, other code in the same file won't be able to access that method. But deprecating things is global, it isn't involved with any visibility.
If one marks a class as 
Deprecated
, the author essentially is discouraging others to use this class, right? How is using any method of the class not the same as using that class?
s
What if you already had deprecated methods in the class? If a consumer of that class is not able to migrate immediately to a different one, how do they distinguish between methods that they should and should not still use?
The ethos behind deprecating a class and individual methods within a class is inherently different, though subtly so
the difference is category - the logic you apply towards deprecating a class is oftentimes not applicable towards individual methods
o
What if you already had deprecated methods in the class?
Then deprecating a class wouldn't make a difference. The method is deprecated either way.
s
you have not addressed the second part of that message…
o
I don't know what you mean by it. The consumer can now if a method is deprecated if the class is deprecated or the method is deprecated
s
it can now
?
o
Now if there is class with 20 methods, and the author wants to mark it as deprecated, deprecating the class wouldn't do it, he needs to add the tag to every single method
s
There really is no need, a consumer of that class can tell that the class is itself deprecated and eventually migrate off of it
IntelliJ will just strikethrough the class instead of the method
the effect of “you should not be using that class” is still achieved
“you should not be using that method” usually suggests there’s a better one in the same class you should be using if you have to
o
But what if that use of the class is just only defined in the top of the constructor. All of its uses in methods wont be strikethroughed
d
Also, if a class implements an interface (that isn't deprecated), does it make sense to mark the overridden methods as deprecated, even though the deprecation will essentially disappear when using poly-morphism?
âž• 3
s
after all, deprecating an API is very different from deprecating an implementation of it
👆 2
o
I get the point, it's more that I am using the UseCase pattern, where you have an interface with a single 
operator invoke()
method. It feels that I should both mark the class and the invoke method as deprecated, duplicating the annotation with its message.
s
to reiterate on the point currently being made, you really don’t want to deprecate the 
invoke()
method, because that suggests to the consumer that 
invoke()
is not the way you should be using that interface — what you really mean is that that class you’ve deprecated shouldn’t be used
there is no point in doubling down on deprecation annotations here
o
I grasp the concept now, thanks.
đź‘Ť 1
Open in Slack
PreviousNext
Powered by