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?

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.
–
EASIJul 27 '13 at 13:05

7 Answers
7

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.

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.

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.

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.
–
AaronaughtFeb 7 '10 at 20:45

2

@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.
–
DelticsFeb 7 '10 at 22:54

7

@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.
–
AaronaughtFeb 7 '10 at 23:12

3

@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.
–
AaronaughtFeb 8 '10 at 0:13

4

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.
–
AaronaughtFeb 8 '10 at 0:16

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.

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.

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.
–
Warren PFeb 8 '10 at 18:25

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:

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

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

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.

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.
–
DelticsFeb 9 '10 at 0:48

4

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?
–
Warren PFeb 9 '10 at 18:47

1

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.
–
DelticsFeb 9 '10 at 20:54

1

So fine, you don't like it, and don't need it. I find it incredibly useful.
–
Warren PFeb 22 '12 at 16:02

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)

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.

Your answers are usually quite helpful. This one is not.
–
ArgalatyrFeb 7 '10 at 22:13

1

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.
–
DelticsFeb 7 '10 at 22:57

1

Agree with the above. Your comment is not helpful.
–
Warren PFeb 8 '10 at 18:17

1

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.
–
DelticsFeb 9 '10 at 0:49

2

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.
–
Warren PFeb 9 '10 at 18:46