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

[Namenloser]

Zitat von himitsu:

Zitat von JamesTKirk:

Was möchtest du da genau? Hättest du da vielleicht ein Beispiel?

(angenommen dort sind bestimmte Typen im Record, wie z.B. Strings, dyn. Array oder Interfaces)

Delphi-Quellcode:

var
  X, Y: TMyRecord;
begin  << X und Y werden initialisiert (wenn dort bestimmte Typen drauf sind)

Y := X;  << es wird eine Kopierfunktion aufgerufen, welche den Record kopiert

end;  << es wird eine Funktion aufgerufen, welche den Record freigibt

In diesen schon vorhandenen Funktionen muß man nur noch schauen, ob in der RTTI des Records die neuen Operatoren stehen und ruft sie dann auf.
Es gibt schon seit langem einen EDN.Eintrag von mir, aber auf mich hört ja keiner. (vorallem da es keine großen Änderungen mit sich zieht)

Das hab ich mir auch schon gewünscht. Ich habe mich schonmal mit einem Interface beholfen, das in einem Record verpackt ist. Ist aber ein ziemlicher Hack.

Das traurige ist ja, dass entsprechende Funktionen zum Finalisieren von Records und Arrays ja bereits vorhanden sind – sieht man auch im Assembler-Code. Nur leider gibt es keine Möglichkeit, sich dort einzuklinken.

[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 von himitsu:

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 ).

Gruß,
Sven

[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 von himitsu:

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.

[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.

[CCRDude]

Zitat von himitsu:

Eine Möglichkeit gäbe es.

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

Geht das inzwischen? Ich hatte das zuletzt mit Delphi 2006 probiert (um Patches zur Win9x-Kompatibilität einzupflegen), da scheiterte es aber immer an der Variants.pas (diverse andere Probleme, wie benötigte aber nicht mitgelieferte obj-Dateien liessen sich anderweitig besorgen).