$M+, IInvokable, RTTI - Wozu?

[Der schöne Günther]

Das ist vielleicht etwas viel Text. Das liegt daran, dass ich die ganze Thematik irgendwie nicht verstehe.

Letzten Dienstag bei Embarcadero's Skill Sprint-Folge zu "AOP mit DSharp" von Nick Hodges (Aufzeichnung ist leider noch nicht hochgeladen) kam überall dieses komische IInvokable -Interface vor.

Auf die Frage, was das soll konnte mir der gute Herr Hodges keine konkrete Antwort geben. Nur dass es DSharp hier brauchen würde. Andere Frameworks wie Delphi Mocks würden sich angeblich ebenso verhalten. Aus diesem Grund würde er sogar empfehlen, Interfaces grundsätzlich allesamt von IInvokable statt IInterface abzuleiten.

Nun gut- Zum ersten mal schaue ich, was System.IInvokable überhaupt ist.

Dem Source nach nichts weiter als {$M+}IInvokable = interface(IInterface) end; {$M-} . Der Hilfe-Artikel Aufrufbare Interfaces im Überblick spricht

Zitat:

IInvokable ist nahezu identisch mit dem Basis-Interface (IInterface), mit dem Unterschied, dass dieses Interface mit der Compiler-Option {$M+} compiliert wird. Mit der Compiler-Option {$M+} wird sichergestellt, dass das Interfaces sowie alle ihre Nachkommen RTTI beinhalten.

. Danach fängt der Artikel leider an, irgendetwas wirres von Webservices zu reden.

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.

Richtig soweit?
Wenn es wirklich so einfach war:

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?

[Daniel]

Ob "alte" oder "neue" RTTI ist unerheblich, wenn man die Metadaten explizit unterdrückt, dann legt man auch die neue RTTI still.
In den Projekt-Optionen kannst Du dies global für Dein Projekt einstellen, im englischen Delphi heißt diese Option "Emit run-time type information". Die Standard-Typen erfordern hier keine weitere Behandlung, diese verfügen bereits über die Metadaten - u.a. deswegen werden EXEn ja stets eine Handbreit größer.


Ich empfinde die Aussage von Nick pauschal immer von IInvokable ableiten zu sollen, als zu kurz gegriffen. Oder einfach als falsch. Genau dann, wenn man die Metadaten braucht, mag es richtig und das Mittel der Wahl sein - wenn man die Metadaten nicht benötigt, ist es überflüssig. Und nur auf den Verdacht hin, dass man später irgendwann mal was in der Richtung benötigen könnte, würde ich meine Klassen- bzw. Interface-Architektur nicht designen wollen.

[Der schöne Günther]

Gesetzt mit dem Bild im Anhang habe ich den richtigen Compilerschalter erwischt- Warum bekomme ich, egal ob an oder aus, zur Laufzeit eine

Code:

EInvalidOpException: 'The type parameter "TProc" contains no RTTI. Please check for {$M+}.'

Code lasse ich weg, ich will einfach nur ein Spring.Event<TProc> anlegen.

Ich dachte, mit diesem Schalter hätte der Typ "TProc" dann die RTTI-Informationen?


Oder ist TProc hier eine Ausnahme?

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

[himitsu]

Das {$M+} gibt an, daß die Standardsichtbarkeit der Property in den nachfolgenden Klassen von Public auf Published gelegt wird.
Somit können die Streaming-/Zugriffscodes also immer diese Property finden/auflisten.
Das betrifft nicht nur IInvokable, sondern auch TPersistent/TComponent, was vorallem von der VCL verwendet wird.

Also in dieser Klasse und deren Nachfahren werden Property standardmäßig published gemacht, wenn man davor keine explizite Sichbarkeit (private/publich/...) angibt.

Published-Property landen immer in der RTTI (egal ob Alte oder neue/erweiterte RTTI), selbst wenn man alles Mögliche von der RTTI deaktivierten würde.

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