public boolean equals(Object other) {
try{ return equals((Thing)other) } catch { return false; }
}
Here the semantics are entirely wrong. Imagine we have apples and oranges. Do we want a false when comparing apples to oranges, a runtime exception or a compile error. I vote compile error. Object oriented programming votes so as well. It doesn't have anything to do with purity. --- Generics give a big help here and can enable the compiler to do much more to the help of OOP than without (think .net 2 and .net 3; collections and generic collections).As for the second example, when your very query is made up of a type, we can't argue that dealing with types as regular data is allowed.
However in this case it was about statistics, which should come at the very end without code being built on top of it. I am sure the problem is however ill-posed as it is mixing the type as data (shouldn't gui components be described in some data representation instead). It is at least that this knowledge is necessary when you take those kinds of shortcuts.
Serialization and communication in networks raises a hard point against me. The case is that indeed we need to be branching on a some variant of instanceof since all we have is a data representation of the type. The thing is annoying however, and people do strive to encapsulate that away with protocols like RPC and so on. So the conclusion is: although there may be no way away from branching on a serialization of a data type (the data representing a class), you should encapsulate that so that other code does not have to do an instance of. --- Once the object is out from the wire, we're back to OO Land where instanceof use is shunned.