comment on

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);
}
[download]

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
[download]

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 !$@;
[download]

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.

--
sgifford's Web page

In reply to Re^5: Runtime introspection: What good is it? by sgifford
in thread Runtime introspection: What good is it? by BrowserUk

Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
Want more info? How to link or How to display code and escape characters are good places to start.


Your skill will accomplish what the force of many cannot
	PerlMonks