Why should I care about RTTI in Delphi?

views:

1054

answers:

+24 Q:

Why should I care about RTTI in Delphi?

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?

+9 A:

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.

Mason Wheeler 2010-02-07 15:11:44

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 P 2010-02-08 18:25:40

+26 A:

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?

Aaronaught 2010-02-07 15:31:59

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

Deltics 2010-02-07 19:59:41

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.

Aaronaught 2010-02-07 20:45:43

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?

Mason Wheeler 2010-02-07 22:51:25

@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.

Deltics 2010-02-07 22:54:44

@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!

Aaronaught 2010-02-07 23:10:28

@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.

Aaronaught 2010-02-07 23:12:16

@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?

Mason Wheeler 2010-02-07 23:57:13

@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.

Aaronaught 2010-02-08 00:13:27

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.

Aaronaught 2010-02-08 00:16:09

Ah! OK, that makes sense! Thanks for clarifying it.

Mason Wheeler 2010-02-08 01:37:25

Does LINQ use .NET reflection?

Warren P 2010-02-08 18:26:34

@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.

Aaronaught 2010-02-08 19:39:33

@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.

Robert Giesecke 2010-02-11 15:37:07

+8 A:

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.

LachlanG 2010-02-07 19:31:23

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.

Warren P 2010-02-08 18:16:35

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.

Deltics 2010-02-07 20:02:18

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

Argalatyr 2010-02-07 22:13:52

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.

Deltics 2010-02-07 22:57:15

Agree with the above. Your comment is not helpful.

Warren P 2010-02-08 18:17:15

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.

Deltics 2010-02-09 00:49:21

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 P 2010-02-09 18:46:37

+1 A:

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.

Warren P 2010-02-08 18:22:12

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.

Deltics 2010-02-09 00:48:30

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 P 2010-02-09 18:47:28

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.

Deltics 2010-02-09 20:54:35

ansaurus

tags:

views:

answers:

Why should I care about RTTI in Delphi?

related questions