[fpc-devel] .NET Reflection vs RTTI

[Marco van de Voort]

> Op Tue, 20 Nov 2007, schreef Marco van de Voort:
> > > 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...
> > 
> > Note that all this can be remedied (and better) by a simple code generator
> > (e.g. codesmith), as long as you alone control the project.
> 
> Ok, but the question to be asked is why would you want to write a code 
> generator if the compiler can generate usable RTTI for you?

RTTI is only half (you need to write the RTTI inspecting code anyway), the generated code is
well integrated, and because there is an higher abstraction level you can
perform checks.
 
> If you want you can say the whole concept of RTTI is nonsense, since you 
> can make those data structures yourself. However, the fact that the 
> compiler generates them, saves you the work of writing and maintaining 
> those RTTI data structures.

I'm not against RTTI, but it simply must not be overrated.
  
> > The .NET framework however also needs these attributes to interact with
> > Windows server components as IIS, and I can also imagine this, when used
> > sparingly applies to other server component vendors (hi Thorsten) too.
> 
> Attributes are IMO syntactic sugar for:
> 
> const datatype1_attributes:Tdatatype1_attributes=(
>         rtti:typinfo(datatype1),
>         attribute1:value1,
>         attribute2:value2,
>         attribute3:value3
>       );

In a statically compiled language, yes. .NET probably pulls them out of the
JIT context for the relevant assembly when needed. Can do an extra JIT pass
even if it needs them.

I don't know what you are getting to with the rest of your msgs.