Prototypenbasierte Objekte

[shmia]

Ich habe mir hier eine Implementierung für prototypenbasierte Objekte gebaut.
Damit ist es möglich, Daten-Objekte z.B. so zusammenzubauen:

Delphi-Quellcode:

var
   haus, tuer, FensterBase, Fenster1, Fenster2 : OleVariant;
begin
   haus := CreateOleObject('PropertyStoreLib.PropertyStore');
   haus.Values['Baujahr']   := 1978;
   haus.Values['Preis']     := 145000.0;
   haus.Values['Architekt'] := 'Anton Nullblick';

   tuer := CreateOleObject('PropertyStoreLib.PropertyStore');
   tuer.Values['Type']       := 'Door';
   tuer.Values['Preis']      := 870.0;
   tuer.Values['Hersteller'] := 'Kalmann GmbH';

   FensterBase := CreateOleObject('PropertyStoreLib.PropertyStore');
   FensterBase.Values['Type']       := 'Window';
   FensterBase.Values['Hersteller'] := 'unbekannt';
   FensterBase.Values['Preis']      := 0;

   Fenster1 := FensterBase.Clone;  // FensterBase wird zum Prototyp für Fenster1
   Fenster1.Values['Preis']      := 350.0;
   Fenster1.Values['Breite']     := 1.60;
   Fenster1.Values['Hoehe']      := 1.10;

   Fenster2 := FensterBase.Clone;
   Fenster2.Values['Preis']      := 460.0;
   Fenster2.Values['Breite']     := 2.25;
   Fenster2.Values['Hoehe']      := 1.10;

   Fenster2.Parent.Values['Hersteller'] := 'Braas';

   haus.Values[1] := tuer;  // tuer wird zum Unterobjekt vom haus
   haus.Values[2] := Fenster1;
   haus.Values[3] := Fenster2;

Wer sich mit prototypenbasierten Programmiersprachen wie JavaScript, Self oder IO auskennt,
kann mir vielleicht Hinweise geben, was man noch beachten muss.

Da man ja ganz beliebig Objekt in Objekt verpacken kann, darf ein Kind-Objekt sein Vater-Objekt enthalten was dann aber zu dem Problem führt, dass der Speicher wegen zirkularen Referenzen nicht mehr freigegeben wird.

Ideen, Anmerkungen?

[Stevie]

Ich hätt ja nen invokable variant type gebaut dafür. Dann sieht das ganze weniger wie nen Dictionary aus und man kann sogar theoretisch nen Variant durch ein konkretes Objekt ersetzen ohne sonst etwas am Code zu ändern.

Nette Sache aber leider in Delphi absolut grausam, da keinerlei Compiler support.

[shmia]

Zitat von Stevie:

Ich hätt ja nen invokable variant type gebaut dafür. Dann sieht das ganze weniger wie nen Dictionary aus und man kann sogar theoretisch nen Variant durch ein konkretes Objekt ersetzen ohne sonst etwas am Code zu ändern.

Nette Sache aber leider in Delphi absolut grausam, da keinerlei Compiler support.

Genau soetwas hatte ich auch vorgehabt.
Allerdings muss ich wohl auf TInvokeableVariantType (weil noch Delphi 5) verzichten und direkt die IDispatch-Funktionen GetIDsOfNames() und Invoke() implementieren.

Zitat von Stevie:

Nette Sache aber leider in Delphi absolut grausam, da keinerlei Compiler support.

Ich möchte mit den Objekten VBScript- und JScript-Funktionen aufrufen und auf diesem Weg bequem Daten zwischen Anwendung und Script austauschen.
Bislang musste ich für komplexe Argumente entweder ein Variant-Array oder ein COM-Objekt verwenden.
Eine weitere Anwendungmöglichkeiten wäre die Objekte zur Interprozesskommunikation zu benützen.
Man könnte die Objekte auch zur Serialisierung von JSON benützen.

[Thom]

Zitat von shmia:

Ich möchte mit den Objekten VBScript- und JScript-Funktionen aufrufen und auf diesem Weg bequem Daten zwischen Anwendung und Script austauschen.

Dann schau Dir mal die Delphi2JScript-Bridge im Delphi Framework für Google Maps an. Genau das wird dort gemacht.

[Furtbichler]

ich finde solche Objekte ganz lustig, aber wie schon erwähnt: Ähnlich einem Dataset ohne persistente Felder (also Zugriff über myDs['Fieldname'] ) ist das Auffinden von Rechtschreibfehlern (Propertyname) sehr schwer.

Ich sehe bisher keinen großartigen Nutzen. Mir sind Wrapperklassen immer noch am liebsten, die den Zugriff auf eine Eigenschaft kapseln. Dann muss ich nur an einer Stelle ändern, wenn sich der Name der Eigenschaft ändert.

[himitsu]

Schade ist bei sowas, daß dann unter Anderem die Codevervollständigung fehlt.

Hatte mal ein Projekt versucht auf sowas umzustellen, aber die Nutzung war dann nicht mehr so schön,
obwohl es teilweise schon gebrauchbar ist, nur eben daß dann das Feld erst zur Laufzeit geprüft wird und einem der Compiler garnicht helfen kann.

[Thom]

Zitat von Furtbichler:

ich finde solche Objekte ganz lustig, aber wie schon erwähnt: Ähnlich einem Dataset ohne persistente Felder (also Zugriff über myDs['Fieldname'] ) ist das Auffinden von Rechtschreibfehlern (Propertyname) sehr schwer.

Schon mal davon gehört, daß sich solche Bezeichner auch als Konstanten definieren und nutzen lassen?

Zitat von Furtbichler:

Ich sehe bisher keinen großartigen Nutzen. Mir sind Wrapperklassen immer noch am liebsten, die den Zugriff auf eine Eigenschaft kapseln. Dann muss ich nur an einer Stelle ändern, wenn sich der Name der Eigenschaft ändert.

Was - außer Vorurteile - hindert Dich daran, das auch zu machen?

Delphi-Quellcode:

const
  MyPropertyName = 'MyProperty';

type
  TMyObject = class([...])
  private
    procedure SetMyProperty(const Value: Integer);
    function GetMyProperty: Integer;
  public
    property MyProperty: Integer read GetMyProperty write SetMyProperty;
  end;

procedure TMyObject.SetMyProperty(const Value: Integer);
begin
  Values[MyPropertyName]:=Value;
end;

function TMyObject.GetMyProperty: Integer;
begin
  Result:=Values[MyPropertyName];
end;

Und damit hast Du, lieber himitsu, auch Deine Codevervollständigung.

[himitsu]

Aber nur wenn man diese Property einführt.

Was aber (ohne Generics) bei meinem Projekt nicht möglich war.

[Thom]

Achso - das ging aus Deinem Beitrag nicht hervor.

[shmia]

Ich weiss nicht, ob das Prinzip hinter dem hier besprochenen Sourcecode jedem klar ist.
(hätte ich vielleicht am Anfang erklären sollen)
Man erzeugt ein Objekt und kann nach Belieben zur Laufzeit Key/Value-Paare hinzufügen,
wobei der Key ein String ist und der Value ein Variant.
In manchen Prog.sprachen wird das als Dictionary oder Hash-List bezeichnet.
Soweit ist das noch nichts Besonderes.
Nun kann man aber eine Kopie eines bestehenden Objekts erzeugen, wobei das Child alle Eigenschaften des Parents erbt.
Intern ist das nur ein Zeiger (Property Parent), der auf das Ursprungsobjekt verweist.
Ändert man einen Wert im Parent ändert sich der Wert im Child automatisch mit.
Ändert man dagegen einen Wert im Child-Objekt, bleibt das Parent-Objekt unverändert.

Kombiniert man das mit der Möglichkeit in einem Value wieder ein Objekt zu speichern ergibt das eine sehr vielseitige Datenstruktur.

Im Anhang ist die erweiterte Version wie von Stevie in Beitrag#2 vorgeschlagen wurde.