[fpc-devel] .NET Reflection vs RTTI

[Thorsten Engler]

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

The class itself should have access to that information. It can then use it
to e.g. stream the contents of all/some of it's private fields to/from a
stream.

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

If yes then it's not documented in typinfo.pp:

            tkMethod:
              (MethodKind : TMethodKind;
               ParamCount : Byte;
               ParamList : array[0..1023] of Char
             {in reality ParamList is a array[1..ParamCount] of:
                  record
                    Flags : TParamFlags;
                    ParamName : ShortString;
                    TypeName : ShortString;
                  end;
              followed by
                  ResultType : ShortString}
              );

> > 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 streaming system itself doesn't touch the published fields at all (it
streams published properties and it streams all child Tcomponents). The
published fields are used like this:

Procedure TComponent.SetReference(Enable: Boolean);

var
  Field: ^TComponent;
begin
  if Assigned(Owner) then
  begin
    Field := Owner.FieldAddress(Name);
    if Assigned(Field) then
      if Enable then
        Field^ := Self
      else
        Field^ := nil;
  end;
end;

As you can see, it doesn't care at all about the actual type of the
published field, it simply assumes that it's a Tcomponent or derived and
that it matches. It's trivial to mislead this into assigning a TComponent
instance to string variable if you want by simply having one component with
a published string field with a specific name and then creating another
component with that first component as owner and assigning the Name property
of that component with the name of the string field...

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

That's great. Why don't we just all go back to coding with a hex editor? Or
maybe just 2 switches? The first one to select 0 and 1 and the second as a
clock signal to commit the current bit value of the first one?