pax:

Regarding the following code, i''d suggest this is the type of thing you want to avoid. Because what happens when a new GameObject type is added to the system. This is exactly what virtual functions are for.
I''m no Java expert, so I here''s the example in C++

class GameObject{public:virtual void DoAction( int action, MyDerivedGameObject other ); virtual void DoAction( int action, MyOtherDerGameObject other ); };DoAction(int action, GameObject& subject){subject.DoAction( action, somebodyElse );}}

The idea here is that DoAction() is a ''message'' on a GameObject. This translates as a public member function. Each GameObject class can override DoAction().

What you are looking for is a type of double-dispatch.
Where the method invoked is dependendent upon two dynamic types. One is the type if this ( or self or the object on the lhs ) and the other is a parameter of the method.

You can accomplish this in C++ via overloading the DoAction() method.

Meyer''s Effective C++ and/or More Effective C++ provide examples of how to do this more correctly than my poor example. I''m not sure if the idea translates to Java, but it is based on overloaded methods, so if Java has them, you should be able to do this.

One other thing...

Having worked in a legacy code base which pre-dated RTTI and had its own macros for class type identification I can say that I thoroughly dislike the technique. It can be error prone because of the lack of true checking on casts. ( At least that is what I have experienced.

If the language standard has a facility that meets your needs, I''d recommend using it. It makes it easier for others to understand your code faster. And combined with the C++ casting operators in this case it works more safely than homegrown solutions.

If you want to see the a human-readable string of the type of an object, you can do typeid(MyType).name()

Note that these strings are, of course, compiler dependent and are not really super useful, except for some debugging and under certain pseudo-type laundering cases.

Hi Pax,

I don''t see any use for DoAction-function at all. Why don''t you directly call virtual methods (kill, open, etc.) declared in GameObject and specify the action in derived class? If you absolutely need that DoAction thing, you can overload DoAction with different type of classes derived from GameObject in which case you don''t need to check the type explicitly with instanceof-thingy. For Instance:

DoAction(int action_, Monster &monter_)
{
switch(action_)
{
case KILL: monster.kill(player); break;
}
}

DoAction(int action_, Door &door_)
{
switch(action_)
{
case OPEN: door_. open(); break;
}
}

Cheers, Altair


"Only two things are infinite, the universe and human stupidity, and I''m not sure about the former." - Albert Einstein

Altair,

Sure. Mine was just an example. There may well be better ways of doing things. I used this method in a small text-based sample game I was writing for a book I''m not writing anymore. It worked well in that situation, but I wouldn''t use it for a full-fledged game.

p