Zugriff auf Private Variable aus abgeleiteter Klasse aus fremder Unit

[Blup]

Die Abschnitte public und published definieren die Schnittstelle für den Entwickler, der eine Komponente verwenden möchte. Der protected Abschnitt erweitert diese Schnittstelle für Entwickler, die von diese Klasse ableiten wollen. Eigentlich sollten auch spätere Versionen dieser Klasse immer mindestens die einmal veröffentlichten Properties und Methoden unterstützen.

Wenn der Entwickler es für notwendig hält, kann sich im Abschnitt private dagegen von Version zu Version alles ändern.

Im Prinzip ist ein Hack für den Zugriff auf private Felder immer nur für die Versionen gültig, für die er auch erstellt wurde. Eine Garantie für zukünftige Versionen kann es nicht geben.
Auf bekannte Änderungen in bestimmten Versionen kann man aber mit bedingter Kompillierung reagieren.

Delphi-Quellcode:

interface

uses
  Graphics;

type
  TMyIcon = class(TIcon)
  private
    function GetImage: TIconImage;
    procedure SetImage(Value: TIconImage);
  public
    property Image: TIconImage read GetImage write SetImage;
  end;

implementation

uses
  Types;

type
  THackIcon = class(TGraphic)  // Ableitung von der selben Klasse wie TIcon
  public
{$IFDEF VER180}
    // hier Felder die nur in dieser Version definiert sind
{$ENDIF}
    FImage: TIconImage;        // Felder in der selben Reihenfolge, Typ, Anzahl
    FRequestedSize: TPoint;
  end;

function TMyIcon.GetImage: TIconImage;
begin
  Result := THackIcon(Self).FImage;
end;

procedure TMyIcon.SetImage(Value: TIconImage);
begin
  THackIcon(Self).FImage := Value;
end;

[relocate]

Zitat von Blup:

Die Abschnitte public und published definieren die Schnittstelle für den Entwickler, der eine Komponente verwenden möchte. Der protected Abschnitt erweitert diese Schnittstelle für Entwickler, die von diese Klasse ableiten wollen. Eigentlich sollten auch spätere Versionen dieser Klasse immer mindestens die einmal veröffentlichten Properties und Methoden unterstützen.

Ok, das ist verständlich als reiner Anwender (auch wenn man Entwickler ist) der Komponente soll man gefälligst die Schnittstellen nutzen die vorgesehen sind. Das ist jetzt eben die Schwierigkeit und da ist es dann quasi vorbei mit der OOP wenn man eben kein Zugriff auf notwendige Daten hat, weil nicht vorgesehen.

Zitat von Blup:

Wenn der Entwickler es für notwendig hält, kann sich im Abschnitt private dagegen von Version zu Version alles ändern.

Gut, dass es interne Variablen geben muss, die die innere Funktion Gewährleisten okee, aber dass es keine ordentliche Möglichkeit gibt auf funktionelle Variablen zu zugreifen deren Manipulation für eine Erweiterung notwendig sind nur weil der Komponentenersteller das "fälschlicherweise" als private deklariert hat. Wobei ich hier jetzt eigentlich keine Grundsatzdiskussion lostreten wollte. Die Komponente wie sie ist wurde einfach nicht so programmiert, dass sie mittels OOP erweitert werden kann, fertig.

Zitat von Blup:

Im Prinzip ist ein Hack für den Zugriff auf private Felder immer nur für die Versionen gültig, für die er auch erstellt wurde. Eine Garantie für zukünftige Versionen kann es nicht geben.
Auf bekannte Änderungen in bestimmten Versionen kann man aber mit bedingter Kompillierung reagieren.

Dafür müsste man ja aber erstmal wissen, ob er noch funktioniert.

[Sir Rufo]

Wenn die Quellen vorhanden sind dann würde ich dort eine protected property auf das Feld erstellen. Dann geht es wieder und der Eingriff bleibt auch kontrollierbar

[relocate]

Die Bearbeitung des Sourcecodes möchte ich vermeiden.

Und zwar, weil die ursprüngliche Unit in einer Delphiversion vorliegt und leicht abgewandelt (nicht durch mich, damit sie funktioniert) in einer Freepascalversion. Die abgeleitete Version soll nun für beide Versionen gelten, ohne eben in den Quellcode der Delphi bzw. Freepascalversion "rumzupfuschen" und damit ggf. andere es nutzen können ohne das zu müssen.

Ich habe hier noch eine Option getestet und werde noch eine weitere testen in der Hoffnung einigermaßen "sauber" zu arbeiten.

Gruß relocate und danke für die Antworten

PS.: Könnte jemand probieren ob diese Art Hacks in späteren Delphiversionen (D7 und später) überhaupt funktionieren?!

[stahli]

Ich kann mich dem Wunsch absolut anschließen.

Ich wollte unter VCL und FMX schon einige Bugs beseitigen oder Funktionalitäten ändern, dann waren aber private Felder nicht zugänglich oder Methoden nicht virtuell.

Auf private Felder könnte man ja heutzutage notfalls über die RTTI zugreifen aber sinnvoll ist das sicher nicht.
Nett wäre eine Möglichkeit, dass man die Sichtbarkeit privater Felder in Ableitungen erhöhen könnte (wie man auch öffentliche Propertys später veröffentlicht). Das Feld ist ja da. Der Compiler muss ja den Zugriff lediglich erlauben.

Methoden sollten m.E. standardmäßig virtuell erzeugt werden (wenn man nicht "no virtual" deklariert). In den meisten Fällen denkt man beim basteln doch einfach nicht daran, "virtual" hinter die Deklaration zu schreiben (sofern man nicht selbst noch Ableitungen plant.)
Ob der Compiler nicht nachträglich noch Möglichkeit hätte, eine normale Methode überschreibbar zu machen, bzw. dies zu emulieren, vermag ich nicht zu beurteilen.
Evtl. wäre eine Deklaration "default override" ja realisierbar, wodurch der Programmierer den gleichen Zweck erfüllen könnte, intern das ganze aber anders realisiert wird.


Im Detail will ich mich da nicht zu weit aus dem Fenster lehnen, das Problem sehe ich aber auch als ein solches an.

[Sir Rufo]

Aber euch ist schon klar, dass dabei im Vorfeld der Fehler gemacht wurde und dass soll jetzt OOP wieder rausreissen, indem die privaten Felder doch veröffentlicht werden

Mein klares Votum dazu: Nein, danke.

Vor einiger Zeit gab es hier eine Diskussion, warum private und protected innerhalb der Unit zugreifbar sind, dass wäre doch doof (dafür stellt man strict davor). Jetzt das Ganze wieder andersherum.

Da man für beides Druck auf den Hersteller ausüben muss, tendiere ich dazu, dass der Code geändert, aber nicht der generelle Ansatz.

[stahli]

Natürlich hast Du Recht. Nur ist das unrealistisch.
Allein für FMX zu erwarten, dass alle originalen Controls überarbeitet und auf einen einheitlichen Stand gebracht werden ist ... Träumerei.

Entsprechende Optionen würden es zumindest ermöglichen, die Fehler zu korrigieren. Auch wenn es ein Notbehelf wäre würde ich es gern in Anspruch nehmen wenn ich es brauche.