http://qs321.pair.com?node_id=696639


in reply to Re^4: Runtime introspection: What good is it?
in thread Runtime introspection: What good is it?

I seem to have oversimplified my shapes example. Certainly you can use virtual methods/late binding when you only care about the type of one object, but when you care about more than one, it's not so easy. Here's a better example:
#include <iostream> using namespace std; class Circle; class Polygon; class Shape { public: virtual void intersect(Shape *that); virtual void intersect(Circle *that)=0; virtual void intersect(Polygon *that)=0; }; class Polygon : public Shape { public: virtual void intersect(Circle *that) { cout << "Intersect polygon with circle" << endl; } virtual void intersect(Polygon *that) { cout << "Intersect polygon with polygon" << endl; } }; class Circle : public Shape { public: virtual void intersect(Circle *that) { cout << "Intersect circle with circle" << endl; } virtual void intersect(Polygon *that) { cout << "Intersect circle with polygon" << endl; } }; void Shape::intersect(Shape *that) { cout << "(Determining type of second shape)" << endl; if (dynamic_cast<Circle*>(that)) intersect(dynamic_cast<Circle*>(that)); else if (dynamic_cast<Polygon*>(that)) intersect(dynamic_cast<Polygon*>(that)); else cout << "Not sure about this, sorry!" << endl; } int main() { Shape *shape1 = new Polygon(); Shape *shape2 = new Circle(); shape1->intersect(shape2); }
Shape::intercept has to look at run-time type information to dispatch to the right overload. You can see that because it is called first; the output is:
(Determining type of second shape) Intersect polygon with circle

If you add a new method, you are going to have to modify any program that uses the class anyway, otherwise it will never be called.
It depends on how the different parts of the system are coupled. In my case, the main program simply loaded up a bunch of classes and told them to start working; they would communicate amongst themselves using their various methods. If a new method was added to one loaded class, and another loaded class started using it, the method would be called even though the main program hadn't changed at all.

So it wouldn't work well for the type check to happen in the main program, at least. I suppose it could be broken out into a sub, like this:

package MyModule; sub IsThisReallyMyModule { my $obj = shift; eval { $obj->method1(); $obj->method2(); # ... }; return !$@;
but that's still extra maintenance, and MyModule::IsThisReallyMyModule($obj) is less idiomatic than $obj->isa('MyModule').
Whenever your code gets an instance of that errent class, you use the late binding trick to "re-bless" it on the way in as as above. And then reverse the process (assignment) on the way out.
This is certainly possible, but it strikes me as more hackish and error-prone than just checking the type and working around the bad behavior. Also, re-bless is a trick that's unique to Perl; I'm not aware of any other languages that will let you do that. Your C++ example above wasn't really changing the type in the way that a re-bless does, it was just casting an object pointer to a supertype. I don't know a way to change the behavior of an existing object at the last minute in C++ or Java.

I think the summary of all of this is that run-time type information and reflection are one tool for solving a certain class of problems. For the most part they can be solved in other ways, which may or may not be better than using reflection. Which way is better depends on the problem, and to an extent is a matter of taste.