Störende Elemente der Delphi-Syntax / Vorschläge für neuen Dialekt

[himitsu]

Eine Möglichkeit gäbe es.

Die System.pas verändern, neu kompilieren und dann auch noch alle BPLs neu kompilieren.
Statt einem Operator könnte man Klassenmethoden verwenden, welche jeweils einen vorgegebenen Namen und bestimmte Parameter haben müßten.

Aber vorallem das Ändern der System.pas und vorallem der BPLs, ist nicht grade optimal schön.

[implementation]

Zitat:

Zitat von himitsu (Beitrag 1145819)

Die System.pas verändern, neu kompilieren und dann auch noch alle BPLs neu kompilieren.

Ich dachte, die System.pas sei nur ein Dummy und ihre Funktionalität fest im Compiler verankert?

[himitsu]

Hab ich auch gedacht, aber mit ein paar speziellen Parametern (Einstellungen) seitens des Compilers, soll es möglich sein.

Denn Records haben, vorallem im Zusammenhang mit Mathematikbibliotheken, einige Vorteile.

Objekte => garkeine automatische Speicherverwaltung, der Objektvariable
Interfaces => automatische Freigabe, wenn der letzte Weg ist
Records => automatische Speicherreservierung, Freigabe für jede Variable einzeln, Umkopieren bei Variablenzuweisung usw.

[JamesTKirk]

Wahrscheinlich (ich werde für den Delphi Compiler jedoch keine Hand ins Feuer legen) wird diese geänderte System.pas aber nur funktionieren, wenn das Record auch Felder von "managed" Typen wie Strings, Arrays oder Interfaces enthält. Ansonsten wird sich der Compiler wahrscheinlich denken: "och, da muss ich nichts machen, also machen wir ein einfaches "Verringern des Stackpointers" (Speicherplatz belegen), "Move" (Zuweisung), "Erhöhen des Stackpointers" (Speicherfreigabe, wobei das auch meist durch ein "ret" abgedeckt wird).

Für FPC muss ich erst nachschauen, was der bei Records mit "managed" Feldern überhaupt aufruft :)

Ein wichtiger Punkt ist bei diesem Feature jedoch dabei: ein RTTI Lookup für die "Ereignisbehandlungsroutine" ist relativ aufwendig. Wenn dies also bei jedem Record gemacht wird, dann wird es relativ teuer Records zu verwenden (dann muss man fast schon zu den guten, alten Objects greifen, wenn man den Overhead vermeiden möchte :P ).

Gruß,
Sven

[Blup]

Ich hätte gern Mehrfachvererbung für Interfaces:

Delphi-Quellcode:

type
  MyInterface3 = interface(MyInterface1, MyInterface2)
  end;

var
  v1: MyInterface1;
  v2: MyInterface2;
  v3: MyInterface3;
begin
  v1 := v3;
  v2 := v3;

Mehrere Class-Helper sollten sich für eine Klasse nicht gegenseitig ausschließen.

[himitsu]

Jupp, und auch deshalb muß es direkt von Embarcadero implementiert werden, dann dort könnte man diese Optimierung dann anpassen und auch ein ordentlicher Operator wäre dann möglich/vorhanden.


Mehrfachvererbung geht nunmal nicht. Aus dem selben Grund, warum es auch bei Klassen nicht geht.
Bei den "einfachen" Interfaces werden die Methoden über einen Index aufgerufen.
Bei Interface-Vererbung baut das neue Interface auf das alte auf, also es wird weitergezählt und weiterzählen ist nur für einem Vorfahren möglich, bzw. es können keine Indize mehrfach belegt sein, was bei mehrere Vorfahren aber zutreffen würde.


Für gewisse COM-Interfaces, wo die Methoden über einen Namen aufgerufen würden, würde es theoretisch gehen, aber da die Möglichkeit von gleichen Namen bestünde, ist das also unsicher und somit besser ganz ausgeschlossen.

[Blup]

Zitat:

Zitat von himitsu (Beitrag 1145839)

Mehrfachvererbung geht nunmal nicht. Aus dem selben Grund, warum es auch bei Klassen nicht geht.
Bei den "einfachen" Interfaces werden die Methoden über einen Index aufgerufen.
Bei Interface-Vererbung baut das neue Interface auf das alte auf, also es wird weitergezählt und weiterzählen ist nur für einem Vorfahren möglich, bzw. es können keine Indize mehrfach belegt sein, was bei mehrere Vorfahren aber zutreffen würde.

Ich verstehe deine Bedenken, aber gerade bei Interfaces sind nicht unbedingt die selben Einschränkungen wie für Klassen nötig.

Delphi-Quellcode:

type
  TMyClass = class(TObject, MyInterface1, MyInterface2)
  end;

Selbst wenn beide Interfaces auf die selben Methoden verweisen würden, ist dies kein Problem.

Der Compiler müsste für die Realisierung der Mehrfachvererbung bei der Prüfung von Zuweisungen die doppelte Vererbung berücksichtigen und an dieser Stelle ein "QueryInterface" einfügen.

[himitsu]

Das ist aber keine Mehrfachverwebung.

Es wird nur von TObject geerbt.
Die Interfaces werden nur implementiert. Das eine Objekt wird mit mehreren Interfaces verbunden, was natürlich geht, aber wenn man sich einen Interfacezeiger von diesem Objekt holt, dann zeigt der immer nur auf jeweils eines der möglichen Interfaces.

Das hier ist eine Interfacevererbung (ein Interface erbt von einem anderem Interface):

Delphi-Quellcode:

type
  IMyIntertface = interface(IOtherInterface)
    [MyGUID]
    ...
  end;

Objekte erben nur von Objekten und Interfaces nur von Interfaces ... eine Vermischung der Rassen tritt nicht ein.

[Blup]

Ich wollte nur zeigen was bisher möglich ist und wie der Compiler arbeiten müsste, um Mehrfachvererbung zu ermöglichen. Natürlich ist intern eine Sonderbehandlung durch den Compiler notwendig. Im Detail stelle ich mir das ungefähr so vor:

Delphi-Quellcode:

type
  MyInterface1 = interface
    procedure My1;
    procedure MyX;
    procedure MyY;
  end;
  
  MyInterface2 = interface
    procedure My2;
    procedure MyX;
    procedure MyY(AValue: Integer);
  end;

  MyInterface3 = interface(MyInterface1, MyInterface2)
//  Compiler-Magie -> MyInterface3 = interface()
//  automatisch unsichtbar hinzugefügt ->
    procedure My1;                            // aus MyInterface1
    procedure MyX;                            // aus MyInterface1, MyInterface2 -> nur einmal da eindeutig
    procedure MyY; overload;                  // aus MyInterface1, andere Parameter
    procedure My2;                            // aus MyInterface2
    procedure MyY(AValue: Integer); overload; // aus MyInterface2, andere Parameter
//  vom Entwickler neu definiert ->
    procedure MyZ;
  end;

  TMyObject = class(TInterfacedObject, MyInterface3)
//  automatisch durch den Compiler hinzugefügt: MyInterface1, MyInterface2
    procedure My1;
    procedure MyX;
    procedure MyY; overload;
    procedure My2;
    procedure MyY(AValue: Integer); overload;
    procedure MyZ;
  end;

var
  v1: MyInterface1;
  v2: MyInterface2;
  v3: MyInterface3;
begin
  v1 := v3; // Compiler erkennt Mehrfachvererbung ->  v3.QueryInterface(MyInterface1, v1);
  v2 := v3; // Compiler erkennt Mehrfachvererbung ->  v3.QueryInterface(MyInterface2, v2);

[himitsu]

Und das ist bei den normalen/einfachen Interfaces falsch, denn es geht nicht um Methodennamen ... diese sind vollkommen egal.

Delphi-Quellcode:

  MyInterface1 = interface
    procedure My1;  // Methode 1 (Index 0)
    procedure MyX;  // Methode 2 (Index 1)
    procedure MyY;  // Methode 3 (Index 2)
  end;
  
  MyInterface2 = interface
    procedure My2;  // Methode 1 (Index 0)
    procedure MyX;  // Methode 2 (Index 1)
    procedure MyY(AValue: Integer);  // Methode 3 (Index 1)
  end;

Beim Objekt verlinkt der Compiler nun die Interfaces und hinterlegt, bei den Methodenlisten er Interfaces, die Zeiger zu den jeweiligen Methoden.

Will man nun mehrere Interfaces vererben, dann müßten im abgeleiteten Interface nun jeweiles mehere Methoden zu einem Index hinterlegt werden, was natürlich nicht geht.
Auch den Indize verschieben geht nicht, da es dann nicht mehr zum Vorfahren paßt.

Selbst wenn nur die Indize hinereinander gelegt würden, also die Indize des zweiten Interfaces werden verschoben, ohne daß das Vorfahreninterface wirklich "implementiert" würde, also quasi der Vorfahre wird nur als Vorlage verwendet, wäre das keine sichere Methode, denn wenn man den Vorfahren verändert, würde das eigene Interface verändert.