Re^4: Runtime introspection: What good is it?

Have you heard of or used "late binding"? Try it this way

#include <iostream.h>

class Shape { public: virtual ~Shape(){}; 
    public:
    virtual void ShowType()
    {
      cout << "Shape" << endl;
    }
};

class Polygon : public Shape { 
    public:
    virtual void ShowType()
    {
      cout << "Polygon" << endl;
    }
};

class Circle : public Shape { 
    public:
    virtual void ShowType()
    {
      cout << "Circle" << endl;
    }
};

int main() {
  Circle circle;
  Polygon polygon;
  
  Shape *shape1 = &circle;
  shape1->ShowType();
  
  Shape *shape2  = &polygon;
  shape2->ShowType();
  
}
[download]

Outputs:

c:\test>696596
Circle
Polygon
[download]

This is essentially the same as "re-blessing" a blessed-reference in Perl 5.

If I add a new method to my class, I have to remember to go add a check for that method to all places where it is loaded dynamically.

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. Reflection will tell you that it's there, but it won't tell how to call it, when to call it, what it will do, or why.

So, as you 've got to go in there and modify any program that uses the modified base class anyway, you might as well update the run-time sanity-checking code to test if the objects you are instantiating have been upgraded with that new method also.

And checking that it appears to do the right thing at run-time is just good insurance. Think of it as adding another test to your test suite. Except that it is one that protects your code by checking that other people (whomever writes the plug-ins derived from your plug-in base class), have done theirs.

Easier said than done if your code is a library being used by other programs who are creating the object in question and passing it in.

Okay. Your scenario is that you are providing a library that accepts instances of the errent class, that have been instantiated by code that you did not write.

So, you write your library in terms of the subclass of that errent class as I described above. 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.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^4: Runtime introspection: What good is it? Select or Download Code

Replies are listed 'Best First'.
Re^5: Runtime introspection: What good is it? by sgifford (Prior) on Jul 10, 2008 at 08:00 UTC
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: Read more... (1503 Bytes) `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	[reply] [d/l] [select]
Re^6: Runtime introspection: What good is it? by BrowserUk (Patriarch) on Jul 10, 2008 at 15:59 UTC
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: Okay. It took a while to drag the steps back from my memories of a former life, and I have a feeling that a few of these steps could be eliminated, but try this: #include <iostream.h> class Circle; class Polygon; class Shape { public: virtual ~Shape(){}; virtual void ShowType() { cout << "Shape" << endl; } virtual void intersect( Shape that ) { cout << "Shape:intersect" << endl; } virtual void intersect_( Circle ); virtual void intersect_( Polygon * ); }; class Polygon : public Shape { public: virtual void ShowType() { cout << "Polygon" << endl; } virtual void intersect_( Polygon that ) { that->intersect( this ) +; } virtual void intersect( Polygon that ) { cout << "Intersect Polygon with Polygon" << endl; } void Polygon::intersect_( Circle that ); virtual void intersect( Shape that ) { that->intersect_( this ); +} virtual void intersect( Circle that ) { cout << "Intersect Polygon with Circle" << endl; } }; void Shape::intersect_( Polygon ) { } class Circle : public Shape { public: virtual void ShowType() { cout << "Circle" << endl; } virtual void intersect_( Circle that ) { that->intersect( this ); + } virtual void intersect( Circle that ) { cout << "Intersect Circle with Circle" << endl; } virtual void intersect_( Polygon that ) { that->intersect( this ) +; } virtual void intersect( Polygon that ) { cout << "Intersect Circle with Polygon" << endl; } virtual void intersect( Shape that ) { that->intersect_( this ); +} }; void Shape::intersect_( Circle ) { } void Polygon::intersect_( Circle that ) { that->intersect( this ); } int main() { Shape circle = new Circle; circle->ShowType(); Shape *polygon = new Polygon; polygon->ShowType(); circle->intersect( polygon ); circle->intersect( circle ); polygon->intersect( circle ); polygon->intersect( polygon ); return 1; } [download] Outputs: `c:\test>696596 Circle Polygon Intersect Circle with Polygon Intersect Circle with Circle Intersect Polygon with Circle Intersect Polygon with Polygon` [download] This evolved in the days before RTTI. Whether I'd use it now in preference to RTTI is debateable. I guess it would depend upon the scale of the project and the affects of enabling RTTI. If it could be localised to some small part of a large project, it might be worth the costs. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l] [select]
Re^7: Runtime introspection: What good is it? by sgifford (Prior) on Jul 10, 2008 at 16:23 UTC
Ah, I see, very clever! It uses two virtual method calls, and takes advantage of the fact that once the first is started, the compiler knows the type of that first object and so can find the right overload for the second object's `intersect`. I'm not sure what the advantage would be over the RTTI solution, although it would be interesting to compare the performance. -- sgifford's Web page	[reply] [d/l]


Don't ask to ask, just ask
	PerlMonks