Alternatives for instanceof

Performance Tuning
#21

[quote]It’s a shame that polymorphism doesn’t automatically do this for us… that is, if the object is of type Grape, then it could automatically call .eat(Grape g) instead of .eat(Fruit f). Just pick the most specific type and work your way up until you find a matching function.
[/quote]
Yes, I’ve been complaining about this for years - java is not (was not) truly polymorphic under the non-language-specific definitions I was given as an undergrad, and it’s a huge problem for library developers. But as I understand it the co-variant types of java 5 fix this “oversight”.

The ONLY reason I’ve ever heard for java not doing this originally was that performance would suffer considerably - each function lookup would have a lot of extra overhead (at least one more indirection, more in cases where otherwise it could have been optimized, and potentially many lookups if there are many “possible” matching functions).

#22

They did right when they chose this optimization. 99.99% of use cases are closed systems where mostly every interaction between 2 classes is well-defined. Pluggable architectures may be all the rage these days but they’re inherently slower, more complicated, and as I say, probably not required for 99.99% of the programs that think they need them.

Cas :slight_smile:

#23

[quote]They did right when they chose this optimization. 99.99% of use cases are closed systems where mostly every interaction between 2 classes is well-defined. Pluggable architectures may be all the rage these days but they’re inherently slower, more complicated, and as I say, probably not required for 99.99% of the programs that think they need them.

Cas :slight_smile:
[/quote]
Indeed. Ultimately, I think the use of explicit syntax to activate this aspect of polymorphism is a good compromise. I was always bothered more by the fact that it was practically impossible in java, short of making a proprietary pre-processing language and pre-compiling all classes :(; if there had been any way around it I would have been happy (e.g. in C++ you can override it, if you really really want to).

#24

With Hotspot-class technologies, there is no reason for multiple argument polymorphism to be inherently slower. In same way Hotspot can inline dynamic method calls in optimistic way today and deoptimize it on conflicting class load, multiple argument dispatch could be done by checking only needed combinations of parameters.

SmallEiffel has done similar thing for multiple inheritance (there are no overloaded methods in eiffel, but there is multiple inheritance with explicit overriding of methods). It performed global analysis of entire program and was able to determine what subclasses are possible at which place of program. It was then just a problem of creating dispatch table or binary ‘if tree’ for correct dispatch - with full possibility of inlining the call. As it turns out, majority of calls are known exactly at compile time - so there is no need for dynamic dispatch at all.
Similar thing could be in theory done during runtime, by optimizing/deoptimizing jit like Hotspot. Of course, in patological cases like plus(A,B) defined for hundreds of various parameters and always called on Object,Object as seen in static context, it would be slow - but probably a lot faster than any hand-made solutions.

As far as the need is concerned… I suppose that 95% of current ‘enterprise’ application don’t need objects at all (value objects are just structures with no logic, transactions are managed in SLSB which are plain functions, view/persistence is decoupled from objects in form of disconnected methods, which are put into object just to call it ‘DAO’ or ‘View’…).