[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [jdt-core-dev] Referendum about deprecation warnings
|
Good point. Note that in the case of implementing deprecated methods, no
complaint is issued if the implementation is itself tagged as deprecated.
This is why we want to generalize this behavior...
|---------+------------------------------>
| | "Dave Wathen" |
| | <dave.wathen@canzon|
| | et.com> |
| | Sent by: |
| | jdt-core-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 09/04/2002 12:01 PM|
| | Please respond to |
| | jdt-core-dev |
| | |
|---------+------------------------------>
>-----------------------------------------------------------------------------------------------------------------------|
| |
| To: <jdt-core-dev@xxxxxxxxxxx> |
| cc: |
| Subject: RE: [jdt-core-dev] Referendum about deprecation warnings |
>-----------------------------------------------------------------------------------------------------------------------|
I think this is an excellent suggestion.
This should also apply to overriding deprecated methods which can be
a pain if you need to implement an interface that includes deprecated
methods.
I'd suggest that this should be an option as choice is usually a good
idea. Consider for instance, if a later version of an interface
actually got around to removing a deprecated method the option could
be flipped to identify the locations of deprecated use/overriding of
the removed method (using the old interface with the deprecated
method) so that the deprecated uses/overrides could be removed (and
then compiled against the new version of the interface).
Dave Wathen
Canzonet Limited
Phone: +44 (0)20 8660 5171
Mobile: +44 (0)7968 167934
Fax: +44 (0)870 051 7664
http://www.canzonet.com
mailto:dave.wathen@xxxxxxxxxxxx
-----Original Message-----
From: jdt-core-dev-admin@xxxxxxxxxxx
[mailto:jdt-core-dev-admin@xxxxxxxxxxx]On Behalf Of Philippe Mulet
Sent: 04 September 2002 10:08
To: jdt-core-dev@xxxxxxxxxxx
Subject: [jdt-core-dev] Referendum about deprecation warnings
We get some feedback from people complaining about deprecation warnings
they cannot fix, since they have to preserve existing APIs even after some
implementation portions got deprecated.
A typical example is:
public class X {
/** @deprecated */
public void foo(Y y){
y.bar();
}
}
/** @deprecated */
public class Y {
public void bar(){}
}
In such a situation, the sender is itself deprecated, but still reports are
issued since its implementation uses deprecated members (bar()).
An improvement would be to ignore deprecation warnings located inside
deprecated code. We could add an option for this, or simply change the
existing behavior.
What do you think ?
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
