Warp wrote:
>   "Doing something depending on which type of object *this is" is precisely
> what virtual functions are for, and that's the RTTI C++ has.

OK. I guess "RTTI" and reflection aren't really as related as I thought they 
were. I find languages without metaclass-style operations are exceedingly 
tedious to work with, in the kinds of stuff I usually write. Hence my 
obvious disdain for the limited RTTI that C++ provides. However, yes, I'll 
grant you that virtual functions are indeed based on run-time type 
information. I'd just prefer a version that doesn't require me to 
reimplement in code all the stuff I already told the compiler about.

I'm kind of surprised that copying a virtual function unchanged into a child 
that inherits it changes its functionality.  That seems completely counter 
to the whole idea, to me.

>   I surely can understand why such information could sometimes be useful,
> but it still sounds to me like you are accessing the internals of an object,
> bypassing its public interface, which is something that breaks the basic
> idea of modularity.

You certainly are, when you use features like that, yes. But when the 
interface is made available to do that safely, it provides a lot of 
benefits. It's not how you want to normally interact with an object, but 
rather part of a meta-protocol for interacting with arbitrary objects. It's 
no different really than having a mix-in class, or having methods on the 
base "object" class (for single-rooted languages).

I.e., in much the same way that templates keep you from having to write the 
same code for lots of different classes, things like reflection prevent you 
from having to write the same code *inside* lots of different classes. 
There's nothing that goes on with reflection that you couldn't code manually 
as virtual functions in each class. The reflection just lets you put into a 
library some kinds of functions that would otherwise be scattered into each 
class that wants to use them. For example, with reflection, I could expose a 
class via COM (which is quite object-oriented), and do so without having to 
manually write the COM wrapper - write once, use lots. It's basically 
looking at the same information you already gave the compiler once, and it 
keeps you from having to duplicate the declarations in some second language 
(like string literals or AST structures or ...) so that you can access them.

It's pretty much exactly like sizeof() in C, which lets you invoke malloc() 
without having to do a lot of manual stuff for each particular type of 
struct you want to malloc. It's just looking at compile-time information and 
packaging it up in a way that lets you examine it. It would be kind of silly 
in C to say "you have to manually count up how many bytes you use and store 
that somewhere if you want to allocate a structure on the heap", when you've 
already told the compiler what's in the structure.

Of course, there would be some runtime overhead involved, like storing a 
description of the class (as an AST perhaps) in the executable file.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message