AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

$M+, IInvokable, RTTI - Wozu?

Offene Frage von "Der schöne Günther"
Ein Thema von Der schöne Günther · begonnen am 29. Sep 2014 · letzter Beitrag vom 27. Nov 2018
Antwort Antwort
Der schöne Günther

Registriert seit: 6. Mär 2013
5.425 Beiträge
 
Delphi 10 Seattle Enterprise
 
#1

$M+, IInvokable, RTTI - Wozu?

  Alt 29. Sep 2014, 12:11
Delphi-Version: XE5
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?
Miniaturansicht angehängter Grafiken
attendeeviewerimage005.jpg  

Geändert von Der schöne Günther (29. Sep 2014 um 12:14 Uhr) Grund: Beispiel-Screenshot des Webinars angehängt
  Mit Zitat antworten Zitat
Daniel
(Administrator)

Registriert seit: 30. Mai 2002
Ort: Hamburg
15.354 Beiträge
 
Delphi 10.4 Sydney
 
#2

AW: $M+, IInvokable, RTTI - Wozu?

  Alt 29. Sep 2014, 12:27
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.
Daniel R. Wolf
Admin Delphi-PRAXiS
mit Grüßen aus Hamburg
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
5.425 Beiträge
 
Delphi 10 Seattle Enterprise
 
#3

AW: $M+, IInvokable, RTTI - Wozu?

  Alt 29. Sep 2014, 12:58
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?
Miniaturansicht angehängter Grafiken
rtti.png  
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie
Online

Registriert seit: 12. Aug 2003
Ort: Soest
3.768 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#4

AW: $M+, IInvokable, RTTI - Wozu?

  Alt 29. Sep 2014, 12:59
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.

  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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (29. Sep 2014 um 13:14 Uhr)
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
5.425 Beiträge
 
Delphi 10 Seattle Enterprise
 
#5

AW: $M+, IInvokable, RTTI - Wozu?

  Alt 29. Sep 2014, 13:03
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.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
37.040 Beiträge
 
Delphi 10.4 Sydney
 
#6

AW: $M+, IInvokable, RTTI - Wozu?

  Alt 29. Sep 2014, 13:36
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
5.425 Beiträge
 
Delphi 10 Seattle Enterprise
 
#7

AW: $M+, IInvokable, RTTI - Wozu?

  Alt 27. Nov 2018, 10:34
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?
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:03 Uhr.
Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2020 by Daniel R. Wolf