[fpc-devel] .NET Reflection vs RTTI

[Daniël Mantione]

Op Tue, 20 Nov 2007, schreef Marco van de Voort:

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

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

I don't see why you would need dynamically allocated data structures, 
after all, if you put them into the language, they are static as well.
The extra work and maintenance argument for normal RTTI doesn't hold for 
attributes since attributes as language feature need to be 
written and maintained as well.

Syntactic sugar might still be a good thing, but then it has to be a 
common annoyance for developers; it doesn't make sense to enhance the 
feature with features that are seldomly used. This criterium IMO isn't 
the case here.

Daniël