Re: Incomparable types
"Patricia Shanahan" <pats@acm.org> wrote in message
news:7p9Ag.2315$xp2.360@newsread1.news.pas.earthlink.net...
Thomas Hawtin wrote:
An object of type Class<capture of ? extends Integer> cannot be the same
object as an object of type Class<capture of ? extends String> (unless
you write unchecked code, and null is an odd case). The is no type T
such that Class<T> is compatible with both of those types. No T
simultaneously extends both String and Integer.
Similarly the expression "i instanceof String" and "i == s" are nonsense
and will not compile.
I can see the rule that is being applied, and it is stated in the JLS,
but the rule itself makes no sense to me.
The language allows many comparisons that can never have a true result.
For example, 2==3 is a valid comparison, with the result false.
Trivially true type comparisons, such as ("A" instanceof String) are
accepted.
It is only in the context of type comparisons, and only if the result is
false, that the compiler rejects the comparison at compile time.
WHY?
It really should be a warning instead of an error: "Warning: this will
always yield true/false, so this is probably not you meant, but the code is
still runnable."
I feel the same way about unreachable code. Sometimes I want to
intentionally make code unreachable for debugging purposes, so I wish
unreachable code was a warning rather than an error. With the Eclipse
compiler, you can actually toggle things like these.
- Oliver