[fpc-devel] .NET Reflection vs RTTI

[Michael Van Canneyt]

On Tue, 20 Nov 2007, Thorsten Engler wrote:

> > Apart from the custom attributes and the Invoke, I don't see 
> > what there is extra ?
> 
> No usable RTTI for records
> No usable RTTI for arrays

Granted.

> No RTTI for private, protected and public(!) members (only published)

Private and protected are not your business in the first place, exposing
it through RTTI or whatever is bad design. Public, OK.

> No usable RTTI for published methods (param and return types are just given
> as strings, not as references to other type infos, no information about
> calling convention)

As far as I know, this is generated ?

> No usable type information for published fields (only a name to offset
> mapping is given, no type information at all)
> And so on...

Huh ? of course you know the type, how else can we stream it ?

> 
> > The 'easy access' can be coded in a single day, and could be 
> > made available in TPersistent. It's on my agenda since years.
> 
> Implementing easy and comfortable access to at least the information that is
> available is going to take a lot longer then "a single day". And I never
> said it couldn't be done. But it's a simple fact that with the reflection
> API in .NET you can get absolute any information you could get from reading
> the interface section of the relevant source code with just a couple of
> lines of code, whereas with Delphi/FPC RTTI and and the helper functions and
> record definitions for it that you have to search together all over the RTL
> source you can only get a fraction of that information and only with
> significant research and writing of code.

So: they needed this information for their CLR or whatever, and they decided
to make their own API available through some system calls.

> 
> > 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.
> 
> No different?? Custom attributes allow me to associate pretty much any form
> of custom data with types and their members and discover this data at
> runtime without having to write code which has to get executed at some time
> to add entries into some form of list. 

You don't need this with RTTI either, if coded correctly.
 
> Instead of having to put code into unit initialization sections to build up
> some form of list which associates some type with some additional
> information which has to run during application startup and is almost
> guaranteed to have to allocate memory from the heap to put that information
> with Custom Attributes the compiler can directly bake your custom
> information into the type information it already generates during compile. 
> 
> Much cleaner approach. Much less overhead both in code execution and memory.

I think you code wrong, because all this is not needed :-) 

> > The only use for this is maybe storing DB persistence information.
> 
> I can only assume that you simply have no idea about how and for what
> Attributes are used.
> Take a look here to get some idea about the uses for attributes in just the
> core framework: http://msdn2.microsoft.com/en-us/library/2e39z096.aspx

I have seen it and didn't see anything of practical value for me.

I'm sorry, I am not convinced. To me, they just provided the info they
need to make their runtime engine tick. Big deal; I don't use their engine
in the first place.

But I still fail to see any practical value of this for me as an application programmer.

Unless I am intimately acquainted with the use of all these properties and
types and whatnot, there is nothing I can do with this information. 
(DB storage excepted, and for this you need more info than available through
introspection anyway.)

It's the same as the SOAP story, whole pages of "introspection" specs: 
Absolutely useless. You must know the exact meaning of each type/parameter, 
and when to set it and what the effect is this action has. You'll always 
need knowledge which is not available through introspection, thus rendering 
the very idea pretty much useless...

Ockham's razor leaves nothing from all this. The benefit of this is - in my
eyes - marginal for the application programmer.

Michael.