[fpc-devel] .NET Reflection vs RTTI

[Michael Van Canneyt]

On Tue, 20 Nov 2007, Thorsten Engler wrote:

> > I'm wondering if anybody has sufficient knowledge in this (I don't).
> > Many developers that moved over to the dark side (.NET) using 
> > Delphi.Net or C# always rave about .Net Reflection and how 
> > much better it is to RTTI.
> 
> > Anybody actually know what is better?  What limits are they 
> > talking about in RTTI?
> > I have used RTTI extensively in my work and I don't seem to 
> > have any issues with it, but clearly I am missing something!
> 
> RTTI in native Delphi / FPC is just the pure data structures that the
> compiler generated and by and large you are on your own to decipher them
> once you got a pointer to it. Reflection in .NET on the other hand is a
> higher level object oriented Framework which sits on top of the actual
> metadata and gives relatively easy and comfortable access to that
> information. 
> 
> As far as the information itself that's available through RTTI / Reflection
> is concerned, the type information available in .NET is truly complete, down
> to every field and every method of every type. Also, the ability to
> associate any number of custom attributes with any of the entities that make
> up the type information in .NET is a very powerful tool.
> 
> Another huge advantage of Reflection in .NET over RTTI as provided by Delphi
> and FPC is that given an instance of an object and a MethodInfo object
> describing any of the accessible methods of that object it is trivial to
> call that method using MethodInfo.Invoke(Instance, [Array, Of, Parameters]).
> (Access to fields, properties and event is similar easy using the respective
> *Info objects).
> 
> The combination of this (truly complete type information, easy access,
> custom attributes) makes it rather trivial to e.g. tag private fields of a
> class with the [Serializable] attribute and use Reflection to serialize the
> class to/from a stream.

Apart from the custom attributes and the Invoke, I don't see what there is extra ?

The 'easy access' can be coded in a single day, and could be made available
in TPersistent. It's on my agenda since years.

And I highly doubt the usefullness of the custom attributes. In their
generality, it's not usable. If you want to make it usable, you'll have
to write code anyway, so it's no different from custom written code.
The only use for this is maybe storing DB persistence information.

So if Graeme writes the 'Invoke' then we're all set.

Michael.