Why do you need Introspection?

I've seen this question come up several times since the announcement of the compiler feature. And I've seen several valiant attempts at answering the question in a general case. Generally, these attempts fall into one of two categories:

1) If you have to ask, you probably don't need it
2) When you need it, you'll know

Very deep, eh? ;-) Well, I'm going to take a stab at giving a general and specific response. But I have to admit that I also agree with #1 and #2 above. I'm simply explaining away the corollary question of: "but if I won't need this, why did RS add it?"

Let me start with the last question first: why did we add Introspection support? The short answer is: because we needed it. Of course, it certainly helps that it was the single most-requested item in the feedback system! But at the end of the day, it turns out that we required it in order to provide more powerful features to the user. So now that we have that question answered, I can focus on: why do you need introspection?

I've given examples previously about serialization and unserialization, among other things. And those are very valid uses for introspection. But the more general answer is: because it provides a powerful mechanism that allows programmers to accomplish things they couldn't otherwise do previously (as easily). That's the main reason *any* new compiler feature comes along. Compilers are meant to take the repetitive tasks and abstract them away so that the programmer can focus on accomplishing their goals.

For instance -- why have a for loop, or while loop? After all, they can be accomplished by just using a counter/controller and a goto! The reason is: because it's easier, cleaner and more maintainable!

The same is true of any compiler feature, and introspection is no different. You could serialize and unserialize things before -- you just had to write the code to accomplish them. Same for cloning, or any of the other introspection-friendly features people discuss. The difference is, there's now less code to write.

Introspection gives you a generic way to interrogate an object for its data, and manipulate the object's state. This is a powerful new technique -- but it's also dangerous. So most people tell you "omg, zounds! don't use it!" and they're partially right. Introspection can be a very fragile way to accomplish the same goals that could be accomplished without it. For instance, calling someObject.SomeMethod is less fragile than looking up a method named "SomeMethod" on an instance of someObject and calling Invoke on it. Why? Well, for starters -- just calling the method takes less code! But it's also less fragile because you can rename SomeMethod and get a compile error if you've forgotten to rename its usage everywhere. But with introspection, all of the work happens at runtime -- no compile errors! And errors that happen at runtime are just a fancy name for bugs.

So if you can do all of these things before, and this is so scary and bad to use -- why would RS (or anyone) ever want to make use of it? Because sometimes there's no way around generic programming when you're designing a toolkit.

Let's say you want to have a generic base class that performs a bunch of work on behalf of a subclass. The base class does not have access to the subclass' properties -- so if the base class wants to assign to those properties, it has to come up with some mechanism to have the subclass do the assignment. This gets pretty complicated very quickly. It's also a terrible example to try to talk out in this fashion, so let me get a bit more specific with a real world example:

Let's say that we (REAL Software) want to expose an object model that represents a database to our users. We will generate a class that represents a table, and inside of that class are a bunch of properties that represent the columns. However, we don't want to shove a whole bunch of source code into these generates classes. If we do that, then it suddenly becomes very difficult (if not impossible) to push bug fixes out to users with any of that source code's logic. Instead, we want the logic to live in a base class that we control and that isn't exposed. By doing this, we can fix the bug in one place (if any crop up, of course) and everyone benefits. This also makes the classes we generate a lot cleaner, and less scary.

Now comes the tricky part -- these classes have properties in them that represent the data. So we need a generic way to map the data from the database query onto the concrete class from within the base class. This is where introspection comes in handy -- the base class can do something like this:

dim ti as Introspection.TypeInfo = Introspection.GetType( self )

dim props() as Introspection.PropertyInfo = ti.GetProperties

for each prop as Introspection.PropertyInfo in props

  if prop.Name = "The Database Column Name" then

    prop.Value( self ) = "The Database Column Value"

    exit

  end if

next prop

This is a very generic way for the base class to do all of the hard work, but still assign data into the subclass. Remember, in this particular case -- all of the possible subclasses we ever generate inherit from the same base class. So it's not like we can just push the properties up to the base class so they can be assigned directly.

This is just one of the many uses (or abuses, depending on your school of thought) that you can find for Introspection. There are plenty of other reasons to use it, of course. But if you're pondering why we implemented the feature, hopefully this adds another example to the pile already given. But I still stand by the majority's opinions that you probably won't need introspection in your day to day life -- but when you do need it, it's very hard to live without it.

Oh, and by the way -- I appreciate that you might want to point out all sorts of solutions to the example I gave. You can refrain from doing that though. I'm aware there's always more ways to skin a cat (trust me, I have multiple cats in the house!), and this was just an example. :-)