RTTI Problem

[TurboMagic]

Ok, wen das so ist, muss ich es halt "zu Fuß" umsetzen.
Geht auch, man muss halt nur bei jeder Erweiterung dran denken das nachzuziehen...

[QuickAndDirty]

Edit:
War quatsch

[Uwe Raabe]

Zitat von TurboMagic:

muss ich es halt "zu Fuß" umsetzen.

Oft ist das auch die saubere Herangehensweise, denn nicht immer sollen oder können alle Properties so einfach kopiert werden. Auch dabei sind dann die zukünftigen Erweiterungen die Stolperfallen, die man meist nicht auf dem Schirm hat (weil, "läuft ja alles automatisch").

[himitsu]

Nja, interfaces besitzen offiziell ja auch keine Property, auch wenn mehrere Compiler sowas anbieten (teilweise auch automatisch, für GetXXX- und SetXXX-Methoden).
OK, in der Interfacedeklaration kann es somit nicht drin sein, aber hätte eigentlich dennoch erwartet, dass es Delpgi dennoch in der RTTI auflistet.


Bei Records, welche eventuell irgendwann mal erweitert werden, füge ich manchmal an solchen Stellen ein {$IF SizeOf(TMyRecord) <> 123} {MESSAGE Warn 'guck ma'} {$IFEND} (oder Hint/Error) ein.

Ist das ein eigenes Interface?
Hier wäre es dann vielleicht einfacher, wenn du dir einen anderen Standard ansiehts. (TPersistent.Assign)
Keine Ahnung, ob man für Interfaces auch einen Record-Helper schreiben könnte, falls es nichts Eigenes ist.

[Dennis07]

Zitat von himitsu:

OK, in der Interfacedeklaration kann es somit nicht drin sein, aber hätte eigentlich dennoch erwartet, dass es Delpgi dennoch in der RTTI auflistet.

Interface-Properties sind, wie du oben schriebst, halt keine "echten" Properties. Sie haben auch noch andere Einschränkungen. Sie sind wirklich ausschließlich "semantischer Zucker" und werden vom Compiler nicht weiter beachtet. Interfaces-Properties haben deshalb keine RTTI, du musst sie also entweder über die Klassentypen abgreifen (ginge ja auch), oder über den Getter/Setter-Name.

Zitat von himitsu:

Keine Ahnung, ob man für Interfaces auch einen Record-Helper schreiben könnte, falls es nichts Eigenes ist.

Kann man nicht.

[jaenicke]

Für den Zweck könnte man auch einen Pascal-Skriptparser verwenden. Wenn man die Units mit den Interfaces im Buildprozess als Ressource anhängt, kann man die Informationen von dort ziehen. Da die gleichen Dateien auch zum Kompilieren verwendet werden, sind die Daten auch immer aktuell.

[Uwe Raabe]

Wie ich schon schrieb halte ich den Ansatz, die über die Properties zu iterieren und diese jeweils zu kopieren, - wenn überhaupt mit vertretbarem Aufwand umsetzbar - für ziemlich aufwändig, fehleranfällig und schlecht wartbar. Immerhin muss bei jedem neuen Property geprüft werden, ob sich das so einfach kopieren lässt und das auch sachlich korrekt durchgeführt wird. Nicht immer enthalten die Properties Strings oder numerische Werte. Klasseninstanzen, Interfaces oder auch Arrays werden so nur als Referenzen und nicht inhaltlich kopiert. Das ist in der Regel bei Arrays und oft bei Klassen gar nicht gewollt. Solche Fälle müssten jeweils gesondert behandelt werden, was bei der RTTI-Lösung den Aufwand beträchtlich steigert.

Den empfohlenen Ansatz hat Frank schon mit TPersistent.Assign und seinem Pendant TPersistent.AssignTo angesprochen. Dieses Verfahren ist schon so alt wie Delphi, wird allgemein verstanden und hat sich bei korrekter Anwendung als stabil erwiesen.

Man kann sich die Implementierung in den simplen Fällen (Strings und numerische Werte) vereinfachen, wenn man die einzelnen Felder hinter den Properties einen record verlagert, der mit einfacher Zuweisung kopiert werden kann. Das deckt die ursprüngliche Absicht zur Vereinfachung der Wartbarkeit bereits ab. Da in dem beschriebenen Fall offenbar mit Interfaces gearbeitet wird, sind sowieso schon Getter und Setter vorhanden, die dann auf die Record-Felder umgeleitet werden. Eine mögliche Implementierung der TPersistent.Assign Ableitung sähe dann, unter der Annahme dass TProduct direkt von TPersistent abgeleitet ist, in etwa so aus:

Delphi-Quellcode:

procedure TProduct.Assign(Source: TPersistent);
begin
  if Source is TProduct then begin
    FData := TProduct(Source).FData;
  end
  else
    inherited;
end;

Bei dem Assign mit einem IProduct als Source wird es etwas komplexer und es bieten sich je nach Gegebenheiten mehrere Lösungsmöglichkeiten an:

• Man erweitert IProduct um eine entsprechende Methode, die dann in allen Implementierungen entsprechend gefüllt werden muss.
• Man deklariert ein separates Interface für das Assign, das man dan über Supports abfragt.
• Wenn sichergestellt ist, dass alle Implementationen von IProduct auf TPersistent aufbauen: Assign(Source as TPersistent);

[himitsu]

"beachten" muß der Compiler diese Interface-Property schon,
* denn man kann sie verwenden (wie bei normalen Property wird beim Auslesen/Zuweisen im Code einfach direkt gegen die Getter und Setter kompiliert)
* in den DCU müssen Infos für diese Property ebenfalls irgendwie enthalten sein, damit der PropertyName dann aufgelöst werden kann
* in BPL müssten sie auch drin stehen, damit nach Änderung auch der richtige Getter/Setter aufgerufen wird


OK, unabhängig davon seht es in der TypeInfo des Interfaces definitiv nicht drin und scheinbar leider auch nicht in der Delphi-TypeInfo und RTTI.




Wenn es sich um Interfaces vom Delphi handelt, also mit einem TObjekt dahinter,
dann könnte man das Interface nach TObject casten und stattdessen über die RTTI des Objekts gehn.