Can someone check the below statements for correctness please?

---------------------------------------------------

- A  class itself has always some RTTI of its own. (but that does not describe all the fields/members)

-  other types may also have RTTI (even if they are outside a published section, or even outside a class)

- fields/members can be found via RTTI  if they are published. That is the field/member can be looked up by name within the RTTI of the class.

   (and that returns the RTTI for the field's type / and the location or getter/setter of the field)

So for the "published" case the DW_TAG_Member needs to have the flag (indicating the presence of RTTI)

(actually indicating that the containing type has type info for that field, and its type)

I'll have to double check the below with the fpc team, to make sure I got the nitty gritty parts correct.

RTTI may also be available for a type. Then the type would want to have that flag, but that would not relate to the published concept.

Some types have always RTTI for the type. Such types could be declared scoped inside a class. But that would not mean they are published.

Afaik (and as I said, I am double checking that)

type

   TFoo = class

   public type

        TMyEnum =(mon,tue,wed,thu,fri);

  public

        FMyAnonEnumVal = (Jan, Feb, Mar, Apr);

   published

        Value: integer;
    end;

TMyEnum has rtti for the type. But can't be looked up by name. (afaik enums always produce RTTI, becaues they can be printed (with writeln) using the name, rather than the stored ordinal val)

The same for FMyAnonEnumVal.

But the published "Value" can also be found by looking up the name "Value" starting from the class.

That could be distinguishable by having the flag on the type (in the 2 public cases), and on the member for the published case.

Yes, if you consider the list of managed fields as RTTI.

-  other types may also have RTTI (even if they are outside a published section, or even outside a class)

Yes.

- fields/members can be found via RTTI  if they are published. That is the field/member can be looked up by name within the RTTI of the class.

Yes.

But they can also be found for private/protected/published fields/methods/properties if the programmer enabled extended RTTI.

   (and that returns the RTTI for the field's type / and the location or getter/setter of the field)

Yes.

So for the "published" case the DW_TAG_Member needs to have the flag (indicating the presence of RTTI)

Yes.

TypeInfo(TSomeType) will generate RTTI for a type. This allows e.g. to convert an enum into a string and vice versa.

AFAIK: Not necessarily.
Only if you
- you write() it
- You have typeinfo(TMyEnum) somewhere
- you have extended RTTI enabled for the class.

But can't be looked up by name. (afaik enums always produce RTTI, becaues they can be printed (with writeln) using the name, rather than the stored ordinal val)

I think the compiler detects whether it is actually used and only emits it then. Needs verifying.

Yes.

Michael.

Martin Frb wrote

- A class itself has always some RTTI of its own. (but that does not describe all the fields/members)

Correct

- other types may also have RTTI (even if they are outside a published section, or even outside a class)

All other types also have RTTI (except *currently* TP-style objects and file types, but I do intend to change that). In addition to that managed types may have a Init RTTI that's different from the full RTTI.

Whether the RTTI is included in the final binary or not depends on whether it's used (e.g. by using TypeInfo() or indirectly by other RTTI) and the linker settings (smart linking).

Correct. Though this is also the case if extended RTTI for methods/fields/properties is enabled for the corresponding visibility sections while a class, record or object is parsed.

The RTTI for types also exists for non-structured types, so it makes no sense to put the RTTI below the type.

Once we have support for iterating through all types it would indeed be possible to look up a type's RTTI by name (assuming it's linked in).

Regards,
Sven