[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 g=
iven
> > 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=3D(
        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=EBl