Why should I care about RTTI in Delphi?

Question

I've heard a lot about the new/improved RTTI capabilities of Delphi 2010, but I must admit my ignorance...I don't understand it. I know every version of Delphi has supported RTTI...and I know that RTTI (Runtime Type Information) allows me to access type information while my application is running.

But what exactly does that mean? Is Delphi 2010's RTTI support the same thing as reflection in .NET?

Could someone please explain why RTTI is useful? Pretend I'm your pointy haired boss and help me understand why RTTI is cool. How might I use it in a real-world application?

Office

Look for TMS Aurelius and you will see that RTTI Attributes are very useful in terms of creating a ORM DataBase Framework and XML serialization into pure objects and the oposite too. – Itin

Answer 1

RTTI in Delphi is still not quite as full-featured as Reflection in .NET or other managed languages, because it is operating on compiled code, not an Intermediate Language (bytecode). However, it is a very similar concept, and the new RTTI system in Delphi 2010 brings it a lot closer to reflection, exposing an entire object-oriented API.

Pre-D2010, the RTTI was pretty limited. About the only thing I ever remember doing with it was converting an enumerated type to a string (or vice versa) for use in drop-down lists. I may have used it at one point for control persistence.

With the new RTTI in D2010 you can do a lot more things:

• XML Serialization

• Attribute-based metadata (TCustomAttribute). Typical use cases would be automatic validation of properties and automated permission checks, two things that you normally have to write a lot of code for.

• Adding Active Scripting support (i.e. using the Windows script control)

• Building a plug-in system; you could do this before, but there were a lot of headaches. I wasn't able to find a really good example of someone doing this from top to bottom, but all of the necessary functions are available now.

• It looks like someone's even trying to implement Spring (DI framework) for Delphi 2010.

So it's definitely very useful, although I'm not sure how well you'd be able to explain it to a PHB; most of its usefulness is probably going to be realized through 3rd-party libraries and frameworks, much the same way it works in the .NET community today - it's rare to see reflection code sitting in the business logic, but a typical app will make use of several reflection-based components like an Object-Relational Mapper or IoC Container.

Have I answered the question?

Voleta

imho "No", because ALL of the things you listed were already possible with the RTTI as implemented. – Kazantzakis

I really don't see how; Attributes were definitely not possible before D2010 (TCustomAttribute is new), there were certainly never any DI/IoC frameworks beforehand, XML serialization was mostly impossible because the old RTTI could only find published properties, and Active Scripting was a frequently-discussed but never-solved problem. How would you have accomplished any of those with the old RTTI? Do you have a link to someone that pulled it off? I'm happy to edit the answer if what you say is true. – Voleta

Forgive my ignorance, but what's the point of DI/IoC frameworks anyway? I always had the impression that that was a Java thing that Java needed to fake Delphi-style events because it doesn't have method pointers like Delphi. Or am I thinking of the wrong thing? – Agamete

@Aaronaught: Of course attributes were possible, you simply didn't have compiler magic to help you and had to provide your own "registry" and lookup mechanisms. These "hand-rolled" mechanisms could of course be far more efficient than the general purpose mechanism provided by RTTI. XML serialization was similarly perfectly possible. I cannot provide a link to code because it is commercial in nature, but I can assure you that all of the things you mentioned had been done long before the D2010 RTTI extensions. – Kazantzakis

@Mason Wheeler: You probably use DI in Delphi all the time, just not IoC. DI just means passing in the dependency of a class (i.e. some data-aware component needs a data connection) through the constructor or public property. IoC is a way of resolving such dependencies without ever knowing about a concrete class, just an interface/abstraction. You just say to the IoC container, "I need a data connection", and it gives you a generic interface, often resolving a long chain of dependencies in the process. We have lambda functions and method delegates in C# too but we still use DI, a lot! – Voleta

@Deltics: I take your point, technically anything is possible in a general-purpose programming language. You could implement XML serialization in GW Basic if you wanted. The difference is one of degree, and - IMHO - the degree here is a pretty big one. – Voleta

@Aaronaught: Delphi has had interfaces like that for years (since D3 IIRC,) and most of what you're talking about can be handled through inheritance, either from abstract base classes or interfaces. For example, there are tons of routines that ask for a "TDataset" object. TDataset is an abstract base class that you don't instantiate directly, and you can send it any TDataset descendant without knowing about the inheritance chain. So again, I don't quite see the point. What does the container/framework do that we haven't already had since Delphi 1? – Agamete

@Mason Wheeler: It's hard to fully explain DI/IoC in the space of a comment box, but I'll try again. It's not simply the usage of abstract data types - those have always been around - it's the instantiation of those types. It's not interfaces that are new - I too have used those since D4 - it's the idea that you never actually create the concrete type that implements one. The container does it for you, and if you need to make an application-wide implementation change, it's literally one line of code or configuration to do so, even if construction occurs in 100 different places. – Voleta

Moreover, it's self-evident that this kind of thing has always been possible, but what hasn't been possible is to create a generic framework to do this that will integrate with any application. Perhaps that's what's getting lost in translation; you can do all of these things yourself for applications that you personally control and can easily modify and reason about; what reflection (and the new RTTI) gives is the ability to create reusable framework-level components that perform these tasks, so you're not re-implementing this for every project. – Voleta

Does LINQ use .NET reflection? – Maryjanemaryjo

@Warren P: Linq to SQL and Entity Framework (Microsoft's O/R mappers) do, extensively. Linq by itself does not necessarily use any, it's simply a language syntax and a few important classes and extension methods. – Voleta

@Warren, extension methods in .Net rely on the existence of an attribute (ExtensionAttribute) on the static class and the extension method. So, indirectly, pretty much all of LINQ needs reflection. Even if it doesn't need it at runtime. – Okinawa

Answer 2

D2010's extended RTTI is a lot like C#'s reflection. It gives you the ability to get at any field of an object, or inspect its methods. This has all sorts of potential uses. For example, if you can read any field of an object, you can write serialization code that can work with any object. And the ability to inspect methods and obtain their name and signature makes a class much easier to register with a scripting engine.

To me, that's the primary advantage of extended RTTI: The ability to write code that works with any class by examining its members, instead of writing different versions of the same code over and over, tailored to each individual class.

Agamete

Yes. What frameworks do, essentially, is give you a mechanism, an abstraction, you should be able to reuse that mechanism or abstraction. So, thus, the Framework concept in so many answers ties in neatly with your answer. – Maryjanemaryjo

Answer 3

Most people probably won't use it in a real world application.

The people who will use it are the framework builders. Frameworks such as DUnit make extensive use of RTTI.

With the new RTTI capabilities we should expect to start seeing more advanced frameworks and tools appearing, similar to what is available for .NET. These frameworks will revolutionise your development moreso than RTTI will on it's own.

Gunlock

So, most people will use things that use it, indirectly. But most won't use it directly. Just like most people won't write a component. But EVERYBODY uses them. – Maryjanemaryjo

Answer 4

RTTI in Delphi has always been important since version 1.0. Classic RTTI features include the "published" properties section of Classes, which allowed the Object Inspector and the component designtime features to work. For my purposes, I would often use Published class properties to allow for enumeration of those properties at runtime. To store things from my objects to disk, for persistence.

The Delphi 2010 RTTI extends this classic RTTI massively, so much so that you could be forgiven for thinking Delphi did not even have RTTI until delphi 2010.

I would say the #1 most useful applications of "The New RTTI" are (as several other answers already state) going to be in Frameworks written by the gurus, that:

1. Handle persistence to files or databases. Database and configuration or document saving/loading frameworks and components would use this under the hood.

2. Handle pickling/marshalling/encoding/decoding to and from various over-the-wire formats, like JSON, XML, EDI, and other things.

3. Unit testing was mentioned by someone else (JUnit), but I think perhaps the same frameworks could be really handy for debug and error reporting tools. Given an object passed as a parameter, on the stack, why not have bug reports that can dump all the data that was passed along to a function that failed, and not just a list of functions?

As you can see, some creative people are likely to think of even more uses for this. You could say, that though it does not bring parity to .NET reflection (which another answer speaks more about), it does bring a lot of "dynamic language" features (Think of Perl, Python, JavaScript) to an otherwise strongly typed static-type systems world of Delphi.

Maryjanemaryjo

All of which all already existed before the new all singing all dancing RTTI. I even wrote a persistence framework and unit testing framework myself, without the aid of super-duper RTTI. – Kazantzakis

Would you please write me a stack dump routine using the old RTTI that will dump all class references and all their non-published properties, please, then? Pretty, pretty please? – Maryjanemaryjo

Why? This is just lazy debugging. A stack dump only needs enough information to locate a problem. You then need to create a reproducible test case to investigate the problem. You can then inspect all aspects of the code you need in the DEBUGGER without having to burden your release code with diagnostic baggage that should never be needed. This would be a case of something that, yes perhaps "new RTTI" makes possible, but shouldn't be necessary. – Kazantzakis

So fine, you don't like it, and don't need it. I find it incredibly useful. – Maryjanemaryjo

Answer 5

For me, personally, extended RTTI gave a possibility to retrieve calling convention from the method pointer. However, currently, that code is under conditional directive, because i am not satisfied with it.

(Critics and suggestions on workarond with basic RTTI are welcome, tho)

Buettner

Answer 6

Look for TMS Aurelius and you will see that RTTI Attributes are very useful in terms of creating an ORM DataBase Framework and XML Serialization into pure objects and the opposite too.

Itin

Answer 7

You are supposed to care because they put it on the box. Clearly they think that some people will care.

Whether you actually have a use for it is entirely dependent on the nature of your projects. Since you didn't have it before and don't understand why having it now is a benefit, this would suggest to me that you don't have a use for it. It's then up to you whether to spend the time researching the subject further in order to discover whether you might be able to find a use for it.

Whether that is the most productive use of your time in relation to your projects, again is something only you can know.

Kazantzakis

Your answers are usually quite helpful. This one is not. – Translative

The poster asked us to tell him how RTTI is useful to him. Nobody can answer that without knowing his projects and needs as well as the poster themselves. – Kazantzakis

Agree with the above. Your comment is not helpful. – Maryjanemaryjo

You are of course entitled to your opinions. The 3 examples of things that the new RTTI "make possible" that you gave all existed before "new RTTI". If you are answering a question about "what does this thing make possible that wasn't possible before (i.e. using the previous RTTI and capabilities of the language)", it is itself singularly unhelpful to list things that were patently and demonstrably doable without the need for "new RTTI". I suppose we must allow that perhaps you were simply ignorant of those previous, existing capabilities. – Kazantzakis

Your response was written in a way that was less effective in communicating your intended point, than it would have been, if you were less negative in your tone. – Maryjanemaryjo

Truly pragmatic statement is not necessary pleasing. +1 – Buettner

I can see how, for example, Aaronaught's answer (but only together with the subsequent comments) is better then Deltics'. If I haven't missed the main point, it's the ability to create a framework that distinguishes the new RTTI from its previous implementations. Yet for someone new to it that's a great deal of work: first, to get the hack of RTTI itself, then to start using it for creating frameworks. So I find Deltics' answer, however disagreeably looking, useful, particularly for myself, as I am in the same position as the OP. +1 – Irrepealable