Elegante Methode für Wechsel zwischen load und loadfromfile

[lkz633]

Hallo,

hat vielleicht nicht 100% was mit D8 zu tun, ich schreibs dennoch mal hier herein.

Ich benutze in einem D7 Projekt immer die IXMLDocument- Methode loadfromfile, jetzt bei D8 heisst Sie jedoch nur noch Load

Gibt es eine elegantere Methode als jetzt jedesmal wenn dies vorkommt eine bedingten Compilerdirektive einzufügen?

Gruss lkz633

PS: Hatte schon schlimmste Befürchtungen, da es ja TXMLdocument nicht mehr gibt. Auf Anfragen was ich denn dann machen muss habe ich eine umständliche Lösung über Datasets bekommen. Aber XMLdocument gibt es genauso wie gewohnt unter dem .net Framework

[negaH]

Es gibt Möglichkeiten, ob sie eleganter sind darüber lässt sich streiten.

Delphi-Quellcode:

procedure TXMLDocument_LoadFromFile(XMLDocu: TXMLDocument; const FileName: String);
begin
{$IFDEF Delphi8}
  XMLDocu.Load(FileName);
{$ELSE}
  XMLDocu.LoadFromFile(FileName); 
{$ENDIF} 
end;

Alle Aufrufe von XMLDocu.LoadFromFile(FileName); müssen nun in XMLDocument_LoadFromFile(XML, FileName); umgeschrieben werden, einmalig.

Delphi-Quellcode:

type
  TXMLDocument = class(TXMLBase)
    procedure XYZ1;
    procedure XYZ2; virtual;
    procedure XYZ3; dynamic;

    procedure Load(const FileName: String); virtual;
  end;

  TXMLDocumentCracker = class(TXMLBase)
    procedure XYZ1; abstract;
    procedure XYZ2; virtual; abstract;
    procedure XYZ3; dynamic; abstract;

    procedure LoadFromFile(const FileName: String); abstract;
  end;

procedure Test;
var
  XML: TXMLDocuemnt;
begin

  TXMLDocumentCracker(XML).LoadFromFile();
  
end;

Hier verwenden wir einen abstrakten Nachfahren vom gleichen Vorfahren wie die zu castende Klasse. Dabei muß unser abstrakter Nachfahre EXAKT das gleiche Interface wie die zu castende Klasse besitzen. Das enthält ALLE felder und Methoden egal ob private, protected, public oder published. Die so entstehende Signature deer Klasse ist kompatibel mit der zu castenden Klasse.

Dieser Weg ist gangbar und funktioniert auch ganz gut, trotzdem sollte er nicht benutzt werden, da bei einem weiteren Update der Klassen auch die abstrakte Typcast Klasse geändert werden muß. Da solche Änderungen auf Borland's Seite in der letzten Zeit leider immer häufiger werden, würde ich es nicht benutzen.

Gruß Hagen