As for the speed of instanceof - it depends. It does not have to be slow - for classes, it is perfectly possible to be 2/3 assembler instructions. For interfaces it can be harder.

I suppose that what is killing you is not instanceof itself, but conditional branches (if/else tree). Mispredicted jump is very costly on most architectures. JBanes solution helps here, as you can use tableswitch then, which takes just a single jump (althrough costly).

Anyway, I have heard at some point in the past than casting and instanceof are signs of non-OO programming and I kind of believe it. Of course, it is just a general guide - same as goto can be useful in lexer/parser generation, sometimes instanceof/cast can be best solution. I do not count pre-1.5 collections here, or equals(Object) method - these are java language deficiencies. But if you see method like

Anyway, I have heard at some point in the past than casting and instanceof are signs of non-OO programming and I kind of believe it....Multimethods (runtime polymorphism depending on the argument type past 'this') would be cool...

Yeah, *if* you have all the language-level support for doing full OOP, then you shouldn't see instanceof. Sadly, we're not yet there with full OOP support in java particularly in it's various polymorphic deficiencies (pre-1.5 it only has basic polymorphism). This is a big problem with writing 3rd-party library code, especially user-extensible library code (where what you really want is probably C++ templates + some extras ), where full polymorphism can increase your readability, extensibility, maintainability by a huge leap (if you know what you're doing...).

When I need to pass messages from one entity to another using MessageRouter, I need to know if im passing down to a node or an entity. If its a node, then pass the message down to all its children. If its an Entity then pass it the message.

There will only ever be Entity and EntityNode, so no complicated if else conditional statements.

On a side note, instanceof seemed not to be my bottleneck, infact, it was faster than calling the getType() method !

As many wise men said: Premature optimisation is the root of all evil. And that is what I was doing, premature optimisation.

When I need to pass messages from one entity to another using MessageRouter, I need to know if im passing down to a node or an entity. If its a node, then pass the message down to all its children. If its an Entity then pass it the message.

Does the message router really need to know this? Or should there be a method called 'receiveMessage()' on an Entity and a EntityNode such that for an Entity, the message will be handled by itself, while the EntityNode will forward the message to all of it's contained Entitys. Seems to me that the OO aspect of implementation hiding would come very handy here.

Most of the multiplayer games I've written have used instanceof fairly heavily. The network layer I wrote allows sending any Object over the network to the server. When the server or a client receives an Object, I use instanceof to handle the object appropriatly. For example:

The network layer I wrote allows sending any Object over the network to the server. When the server or a client receives an Object, I use instanceof to handle the object appropriatly.

There are few other solutions. a) Use packet type id in switch statement. b) Add message-handling code to packet class itself - even if it is just calling handler.handle(this) to get static dispatch working (like Cas example)c) use some kind of RMI instead of dispatching method to data manually

So what would you do if your Fruit types were dynamic? Suppose a run-time plugin added Grape, which the Monkey wasn't designed to receive. Grape would somehow have to determine that the target animal does/doesn't have an eatGrape() function. You'd end up with something like "is Monkey instanceof GrapeEater", and then each animal implements a set of xxEater interfaces.

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.

Our system has both run-time dynamic plugin message generators and run-time dynamic plugin message receivers. We use a type combined with the source of the message; that is,

mostly because we didn't want to try to define a unique ID to each type of message (ie, didn't want to create a global message ID namespace). So our message types are only unique within their own source, and we check both.

However, this is little more than a fancy instanceof, and I'm curious what the "proper" solution is supposed to be.

Jokes aside, I don't think that this problem can be solved in generic case. If you have truly dynamic system, with two independent libraries extending base objects, there is no place to put definition of what should happen when these two subclasses will meet. You need to provide some kind of methods which will describe an object in a way which could be changes by just overriding base object methods.

When I think about multimethods, standard method call notation stops to make sense. What is needed is just a possibility to writemethod(ClassA a, ClassB b)and have it to work on dynamic type of arguments (so you will call method(a,b) instead of a.method(b));Second thing needed is ability to define such methods out of scope of any class - and I end up with Nice (http://nice.sourceforge.net/index.html). Anything short of that is just a hack.

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.

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).

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.

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

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).

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'...).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org