arithma wrote@xterm: You are underplaying the importance of the issue by the usual unscientific approach that plagues software engineering that is: "it works either way" and "everything has its pros and cons", however I believe that is akin to resulting in bad arbitrary architectures.
"It works either way" is acceptable in the 21st century with the current state of hardware where the millisecond you would be saving by choosing the most "Optimal" way does not matter. The use of instanceof extends beyond the pushing the design into a bad architecture.
In an object oriented context, this question is the epitome of all questions. It is the analogue of using a for loop using an integer i in a functional programming language.
So it's a matter of being
Pure within the paradigm you're programming in.
The question is put in the strongest form as such:
Is there a programming problem that would require the use of run-time type information to branch onto different behaviors (which includes raising exceptions)?
Again, it's a matter of how much effort is going to be put in order to accomodate the behavior you would be using "instanceof" for, in the object oriented context. If i'm going to have to implement my version of the object's blueprint for every single class that is available JUST to adhere to the OO paradigm, then i'm directly increasing the effort that i'm putting in to solve my problem, as well as the size of my application, just so i can make a few happy. Though notice the contradiction i'm creating based on my previous point concerning the 21st century. See the dilemma ?
The issue here is, not to overuse it.
My answer for that is that if any language does require you using those techniques, then it is by design flawed as to its sticking to the object oriented paradigm.
Based on the nature of instanceof, there's no language that has instanceof, or a similar construct, that cannot solve the problems using plain old OO tricks. But on a side note, languages aren't flawed, programmers are.
Proper handling of these problems would move the type checking from run time to compile time. We all know what feeling it gives us the programmers when an error comes out at a random machine running our program complaining of an unhandled type mismatch exception. It's much better to have the program fail at compile time.
It is definitly much better to move the errors at compile time, but at the cost of the increased effort you're putting in to deal with the problem in an object oriented manner.
There is no reason that a single event handler should receive multiple types of events and branch on that instead of having different strongly typed event handlers. It's bad design to wire different event signals to the same slot if they require different behavior.
And yet, instanceof is overused in this matter.
I am afraid this is not a purist problem as you have put it, instead is a matter of good architecture.
How is enforcing a good architecture at the cost of increasing effort not a Purist thinking?
The real question that you guys should ask is:
What is cheaper in terms of performance? condition or exception handling?
P.S: I wrote this post at 7.30am before having coffee, i'll revisit it later if it needs changing.