[fpc-devel] .NET Reflection vs RTTI

[Thorsten Engler]

> 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
No RTTI for private, protected and public(!) members (only published)
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)
No usable type information for published fields (only a name to offset
mapping is given, no type information at all)
And so on...

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

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

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.

> 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

Cheers,
Thorsten