$M+, IInvokable, RTTI - Wozu?

[Stevie]

Zitat von Der schöne Günther:

Deswegen sieht es für mich bislang so aus:
Es gibt irgendwelche Mechanismen die noch auf die "alte" RTTI aufbauen. Diese Mechanismen brauchen eine explizite Generation dieser RTTI-Informationen für Typen mit denen sie arbeiten sollen.
Und diese Mechanismen stecken wohl in DSharp und anderswo.

Es gibt keine alte und neue RTTI. Es gibt nur die RTTI (die seit Delphi 2010 aufgebohrt wurde, dass mehr Informationen als früher vom Compiler generiert werden - z.B. method info nicht nur für published Methoden - offiziell auch als enhanced RTTI bezeichnet). Zudem kann man noch durch die $RTTI Direktive granular einstellen, wie viel davon erzeugt wird.

Allerdings gibt es 2 verschiedene Wege, an diese Information zu gelangen:
1. Pointergefummel mit dem Krams aus TypInfo und Wissen, wie sie z.b. auf Hallvard Vassbotns Blog zu finden sind - aka "alte" RTTI
2. System.Rtti.pas mit einer higher level API aka "neue" RTTI - greift aber letztlich auf dieselben durch den Compiler generierten Informationen zu.

Zitat von Der schöne Günther:

1. Gibt es einen Compilerschalter mit den ich diese alten RTTI-Informationen zu ALLEN Typen hinzufügen kann? Die Größe der .exe wäre mir egal. Wenn es ginge, hat das einen Einfluss auf die Geschwindigkeit?
2. Falls es keinen solchen Schalter gibt, wie füge ich explizit diese Informationen zu einem bereits vorhandenen Standardtyp (wie TProc) hinzu?

Soweit ich weiß, gibt es diesen Schalter nicht (*). Du musst entweder von IInvokable ableiten oder über die entsprechenden Interfaces das {$M+} (bzw ausgeschrieben {$METHODINFO ON}) schreiben. Der Rat, generell von IInvokable abzuleiten kann ich eingeschränkt bestätigen - die Einschränkung wäre hier: nur, wenn ich irgendwas in die Richtung dynamische Proxies damit machen möchte. Darunter fällt auch sowas wie Delphi Mocks oder DSharp. Beides benutzt TVirtualInterface, um zur Laufzeit einen Proxy für ein Interface zu erstellen, und das braucht die RTTI über die Methoden. Fällt mir das aber erst spät ein oder ich schreibe eine Bibliothek, die von anderen benutzt wird, dann besteht für den Consumer oft keine Möglichkeit mehr, da nachträglich RTTI reinzubekommen.

Zu TProc und Co aus der SysUtils, kannst du keine RTTI hinzufügen, du musst dann deine eigenen Typen deklarieren.

(*) Für den von dir kompilierten Source funktioniert der von Daniel erwähnte Schalter. Allerdings beeinflusst der nicht die in der RTL/VCL/... enthaltenen Typen.
Außerdem macht auf diese Option vertrauen anstatt das explizit in den eigenen Typen anzuschalten mehr Ärger als Nutzen.

[Der schöne Günther]

Zitat von Stevie:

Es gibt keine alte und neue RTTI. Es gibt nur die RTTI

Dann habe ich die oft hier aufgeschnappte Formulierung "alte und neue RTTI" wohl falsch interpretiert. Wieder was gelernt.

[Der schöne Günther]

Zitat von Stevie:

Beides benutzt TVirtualInterface, um zur Laufzeit einen Proxy für ein Interface zu erstellen, und das braucht die RTTI über die Methoden. Fällt mir das aber erst spät ein oder ich schreibe eine Bibliothek, die von anderen benutzt wird, dann besteht für den Consumer oft keine Möglichkeit mehr, da nachträglich RTTI reinzubekommen.

Vier Jahre sind vergangen, und genau darum geht es jetzt gerade wieder: Ein paar Tests für eine interne Bibliothek. Und wenn man grade eine Dummy-Instanz für einen Unit-Test braucht macht es wenig Spaß ständig leere Implementationen schreiben zu müssen. Ein Einzeiler mittels TVirtualInterface.Create(..) hat da schon was, nur muss das entsprechende Interface sich von IInvokable ableiten (oder halt die TypInfos mit Compiler-Direktiven erhalten).

Heißt: Für Bibliothekscode generell von IInvokable ableiten? Mir ist das Interface auch in den letzten vier Jahren nie über den Weg gelaufen, deshalb tue ich mich da so schwer mit.

Gibt es noch mehr Meinungen?