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

[JamesTKirk]

So... es wird Zeit, dass ich mich auch mal in diese Diskussion einmische.

Zitat von implementation:

• Es muss eine strikte Reihenfolge von interface->implementation eingehalten werden. Das heißt, ich kann keine globale Eigenschaft deklarieren, die auf eine private Variable zurückgreift.

Diese Reihenfolge ist einerseits der Tatsache geschuldet, dass Pascal auf Single-Pass-Kompilierung ausgelegt ist (das heißt keine Nutzung darf vor der Deklaration erfolgen (mit wenigen Ausnahmen ala forward oder Pointer auf Records)), anderseits arbeiten "Unit basierte" Compiler wie FPC und Delphi so, dass sie sich beim Kompilieren einer weiteren Unit erst nur den Interface Teil der Unit anschauen müssen, um festzustellen, ob sich was geändert hat und demnach die erste Unit neukompiliert werden muss. Wenn du nun Teile des Implementationbereichs in den Interfacebereich schiebst, so muss der Compiler auch über diese Teile hinweg parsen, selbst wenn er sie eventuell gar nicht benötigt, weil sich nichts geändert hat.

Ganz davon abgesehen ist das mit Interface und Implementation Anfängern einfacher zu erklären als "also wenn du da jetzt noch auf eine private Variable der Unit zugreifen möchtest, dann musst du vor diesem Public Abschnitt noch einen Private Abschnitt einfügen"

Zitat von implementation:

• Interfaces sind per se immer an Referenzzählung und COM-Kompatibilität gebunden. In meinem halbjährigen Ausflug nach C# habe ich erfahren, wie schön es sein kann, a) in Interfaces für Properties nicht gleich eine Getter/Setter-Methode angeben zu müssen, sondern dies der Implementierung zu überlassen, b) Objekt- und Interfacereferenzen mischen zu können

Kann es sein, dass du hier eher (a), (b) und (c) brauchst? Mit (a) also Hinweis auf Referenzzählung und COM...

Nichtsdestotrotz: Free Pascal unterstützt nicht-referenzgezählte Interfaces (so genannte CORBA Interfaces). Die kannst du (per Unit oder eventuell sogar lokal per Deklaration, das weiß ich grade nicht) ganz einfach per "{$interfaces corba}" aktivieren. Du deklarierst dann ganz einfach dein Interface, diese leiten dann jedoch NICHT von IInterface/IUnknown ab (um genau zu sein haben die dann gar keinen Vorfahrn) und benötigen auch keine Implementierungen für QueryInterface, AddRef und Release. Seit FPC 2.4.0 funktionieren die sogar ähnlich wie COM Interfaces hinsichtlich "as" und so (aber eben ohne Referenzzählung).

Zu deinem a): Dies wäre ein Feature, dem ich eventuell sogar eine gewisse Sinnhaftigkeit zugestehen könnte (ich arbeite nur selten mit Interfaces, deswegen...). Solche Interfaces kannst du dann natürlich nur in Pascal Code einsetzen, da zum Beispiel ein C++ Code, welcher dieses Interface verwendet, nicht wissen kann wie er auf die Property zugreift (außer man streut hier sehr viel Compilermagic ein...)

Zu deinem b): Das Problem hierbei ist die Referenzzählung. Delphi und FPC fügen nur Code zum Ändern der Referenzzählung ein, wenn es sich um eine Interface Referenz handelt. Also rein prinzipiell könntest du sie sogar mischen, wenn du manuell mit AddRef und Release auf der Objektreferenz arbeitest... (nicht dass das unbedingt das sinnvollste ist, aber es würde gehen) Falls du dich jedoch darauf beziehst, dass du einer Objektreferenz keine Interfacereferenz zuweisen kannst, dann hat das den Hintergrund, dass ein Interface ja von unterschiedlichen Klassen implementiert werden kann. Diese Klassen müssen dabei ja nichteinmal verwandt sein. Also eine automatische Konvertierung würde ich da gar nicht wollen. AFAIK unterstützen jedoch modernere Delphi Versionen (XE+?) ein "as", um von Interfaces auf Objekte zu casten und wenn das nicht geht wird eine Exception geworfen (wie von "as" gewohnt). Vielleicht gibt es da auch ein "is", das weiß ich gerade nicht. Das wären auf jeden Fall zwei Features, die zu FPC hinzugefügt werden könnten/sollten.

Zitat von implementation:

• Methoden und nichtmethodische Routinen sind im implementation-Teil sprachlich nicht gruppiert (höchstens durch Kommentare)

Das hat mich ehrlich gesagt noch nie gestört (und ich finde deinen Vorschlag dazu auch nicht wirklich eine Verbesserung). Dafür hat man ne gute IDE...

[QOUTE][*]Man kann zwar mehrere verschiedene benannte Destruktoren deklarieren, das hilft aber nichts, weil Free immer nur einen ganz bestimmten aufruft. Wozu haben wir denn unser schönes Benennungsfeature?[/LIST]
Und es funktioniert auch wie es soll. "Free" ist nur eine normale Prozedur deren einziger Sinn es ist zu überprüfen, ob "Self <> Nil" ist und dann den Default-Destruktor "Destroy" aufruft. Nichts hält mich davon ab einen Destruktor mit einem anderen Namen zu definieren und einfach direkt aufzurufen. Es ist nämlich der Aufruf des Destruktors, der die Speicherfreigabe veranlasst, nicht der von Free (sonst bräuchten wir ja kein spezielles Keyword für den Destruktor).

Delphi-Quellcode:

  type
    // Schema-Typ, wie in GPC:
    TCharArray(start, length: Integer) = array [start..start+length] of char;
    TSample = TCharArray(0,6);

Schematypen stehen bei mindestens einem FPC-Entwickler auf der Wunschliste.

Weil's grad zum Kontext passt noch der Einwurf Himitsus dazu:

Zitat von himitsu:

Delphi-Quellcode:

TCharArray(start, length: Integer) = array [start..start+length] of char;
TSample = TCharArray(0,6);

Sieht einfach nur häßlich aus und paßt nicht zur Pascal/Delphi-Syntax.

Im Gegensatz zu vielen der Features die uns lieb sind wie Klassen, Generics, etc. sind Schematypen sogar Teil des ISO-Standards.

Zitat von himitsu:

- die Generics so erweitern, daß man statt typen auch Konstanten verwenden kann.
(würde dann teilweise ähnliche Möglichkeiten bieten, wie die Makros in C)

Ich weiß nicht, ob das wirklich so gut wäre... es wäre schon schwierig sowas zu parsen:

Delphi-Quellcode:

type
  TTest<const c> = class

  end;

var
  TTest: Integer; // was ja erlaubt ist in Delphi! (in FPC funktioniert das noch nicht...)

begin
  if TTest<5>.Irgendwas then 
    ...
end.

Der Compiler muss den Punkt "TTest<5" nun irgendwie intelligent behandeln. Es kann vielleicht schaffbar sein, aber wenn ich mir allein den Code anschau, den ich geschrieben habe, um die Inlinespezialisierung "TTest<SomeType>" zu erlauben, dann möchte ich nicht wissen, was ich da alles verbrechen muss (und dabei hab ich es noch nichteinmal geschafft die Überladung mit einer Variable zu implementieren, das steht noch auf meiner ToDo Liste, weil's (hoffentlich) ein extremes Randbeispiel ist).

Zitat von himitsu:

- ein mehrstufiger Compiler, bzw. ein intelligenterer, so daß man besseren Zugriff auf die Typen hat, welche im denerischen Type enthalten sind.

Kannst du das bitte genauer erklären?

Zitat:

- generische Prozeduren, Interfaces und Class Helper (nicht nur Klassen.Methoden)

Generische Prozeduren werde ich auf jeden Fall mitimplementieren, wenn ich generische Methoden implementiere. Aber Interfaces kann man doch bereits generisch deklarieren, oder verpeile ich da was? Generische Class Helper könntest du übrigens nur in der folgenden Form nutzen, da du beim Aufruf einer Class Helper Methode ja keinen Typen angeben kannst:

Delphi-Quellcode:

type
  TSomeClassHelper<T> = class helper for TObject
    function ReturnDefault: T; // mir fällt grad nichts besseres ein
  end;

function TSomeClassHelper.ReturnDefault;
begin
  Result := Default(T);
end;

type
  TSomeClassHelperInteger = TSomeClassHelper<Integer>;

var
  i: Integer;
...
  i := SomeObject.ReturnDefault;
...

Zitat von himitsu:

- Class Helper Record Helper für einfache Basistypen, wie t.B. den Integer oder den String

- Interface Helper

Du wirst lachen... seitdem ich record und class helper in FPC implementiert habe, denke ich immer wieder darüber nach die auf interfaces, objects und eventuell auch primitive Typen zu erweitern (als FPC-Entwickler darf man die objects nicht vernachlässigen ). Die ersteren beiden sollten vergleichsweise einfach zu implementieren sein (nur bei Interfaces müsste ich aufpassen, dass mir die Referenzzählung keinen Strich durch die Rechnung macht). Primitive Typen würde wohl einige Anpassungen des Parsers nach sich ziehen...

Zitat von himitsu:

- Operatoren für Interfaces

In FPC kannst du diese bereits deklarieren (zwar nicht innerhalb von Interfaces, aber es sollte gehen ).

Zitat von himitsu:

- Operatoren für Copy, Create und Destroy von Records
(technisch leicht möglich, da alle Struckturen schon existieren ... siehe Behandlung der Interfaces, dyn. Arrays und der Strings innerhalb von Records)

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

Zitat von himitsu:

- endlich mal ein Versesserung einiger Grenzen in der OTA
(jbg bekommt auch immer wieder mit, daß Vieles einfach nur fehlt oder schecklich implementiert ist)

- und ein OTA-Interface für einen eigenen Precompiler

Was heißt OTA?

Zitat von himitsu:

- daß man bei dyn. Arrays das CopyOnWrite aktivieren kann, so wie es bei den Strings auch vorhanden ist

AFAIK unterstützt FPC dies auch bereits.

Zitat von himitsu:

- absolute mit einer Typsicherheits- und Größenprüfung (Compilerwarnung)

Solange diese Compilerwarung ein Opt-In ist...

Zitat von himitsu:

- string aus den reservierten Wörtern rausnehmen

Es sieht zwar nicht so schön aus, aber ein &String sollte es doch tun, oder nicht?

Zitat von himitsu:

- ein "caseend" für die varianten Recordteile ("end" geht ja nicht mehr ... das hätte man gleich zu Beginn nicht vergessen dürfen )

Ich glaub "vergessen" ist das falsche Wort. Das wurde damals wahrscheinlich absichtlich so gemacht. Die Begründung könnte vielleicht sein, dass man sich nicht mit einem Case inmitten eines Records herumschlagen wollte (hinsichtlich Memory-Layout).

Zitat von himitsu:

- das Strg+Linksklick auf einen generischen Teil (Methode,Feld,...) nicht bei "implementation" landet, sondern beim generischen Typen

Ehm... was hat das mit der Sprachsyntax zu tun? Das ist ein Problem der IDE...

Zitat von NamenLozer:

• Ich finde, man sollte Variablen immer bei der Deklaration initialisieren können, also nicht nur globale Variablen, sondern auch Felder und lokale Variablen. var x: integer = 0

Zumindest das mit lokalen Variablen kann Free Pascal zum Beispiel. Für Felder geht das nicht.

Zitat von NamenLozer:

• Oft nervt mich die Operatoren-Priorität bei Konditionalen – dass man um Vergleiche immer eine Klammer setzen muss, wenn man sie per AND oder OR verknüpfen will. Ich kenne keine andere Sprache, wo das so ist.if a<b and b<c then ... statt if (a<b) and (b<c) then ... . Wann will man schon mal tatsächlich zwei Werte in einer Abfrage binär verknüpfen? Außerdem wäre das ja immer noch möglich, eben mit Klammerung. Ich wünschte mir hier einfach ein anderes Default.

Das große Problem bei solchen Änderungen ist die Abwärtskompatibilität. Sowas sollte als nur per Compilerschalter möglich sein. Ansonsten schließe ich mich hier im Sinne von "in" an:

Delphi-Quellcode:

if not (SomeEnum in SomeSet) then
// vs
if not SomeEnum in SomeSet then

Dass ich da Klammern setzen muss, hat mich schon immer aufgeregt...

Zitat von NamenLozer:

• Ich fände es außerdem cool, wenn sowas ginge: if a < b < c then ... . Ich glaube Prism/Oxygene kann das.

Waaahhhh!!! Bloß nicht! Meine ganze Logik für if TSomeGeneric<SomeType>.BlaBla fusst darauf, dass genau das eben nicht geht!

Zitat von NamenLozer:

• Hin und wieder nervt mich, dass man im Interface-Bereich Felder immer vor Methoden deklarieren muss.

FPC konnte das früher mal, das wurde jedoch abgeschafft. Begründung siehe hier

Zitat von NamenLozer:

• try ... except ... finally ... end statt zwei try-Blöcke schachteln zu müssen.

Ja, manchmal wäre das durchaus schön (vor allem, wenn man ein paar mehr von den Viechern geschachtelt hat...)

Zitat von Medium:

Mein Wunsch geht zwar über Syntax hinaus, und dafür würden mich sicher hier gerne einige vermöbeln, aber ein Delphi mit GC wäre schon sexy. Ich weiss, es gibt da diverse Fummelein mit Interfaces und Hacks, aber ein richtiger "ab Werk" GC ist einfach eine riesen Komfortsteigerung (wenn er vernünftig umgesetzt ist). Was ich in C# ab und an gern mache, und in Delphi ab und an wünschte, ist sowas wielokaleVarMitRückgabewert := TMyFooClass.Create(aParameter).SomeMethod(aNotherParameter); , und die Instanz dann einfach verpuffen lassen. (Ja, das sieht nach einem Designfehler aus, man meint die Methode hätte statisch sein sollen - aber so schlau sind leider nicht alle Fremdkomponentenhersteller.) Oder auch so Späße, bei denen Instanzen über mehrere Threads eher "locker umher geworfen" werden würden mit einem GC etwas weniger Kopfschmerzlastig.

Vielleicht sogar als alternativer Konstruktor, ggf. mit Einführung des new-Operators!

Delphi-Quellcode:

  bar := TMyFooClass.Create(); // <- normal ohne GC
  bar := new TMyFooClass(); // <- GC'ed

Mit etwas Unterstützung in der IDE (anderes Highlighting für GC'ed Instanzvariablen) wäre so ein Hybrid glaube ich sogar einigermaßen handlich.

Vielleicht weniger über einen neuen Konstruktor gehen, als die Variablendeklaration zu ändern:

Delphi-Quellcode:

var
  bar: TMyFooClass autoref;
begin
  bar := TMyFooClass.Create;
  ...
  // bar wird automatisch freigegeben, falls keine Referenz darauf mehr existiert (die Überprüfung hierzu ist jedoch schwierig)
end;

Wie gut das funktionieren würde, wenn man Objekte über Prozeduren hinweg reicht, weiß ich noch nicht, aber es wäre vielleicht eine Idee...

Zitat von himitsu:

Wenn man Klassen direkt als Interface markieren könnte, bei deren Deklaration, ohne vorher einen extra Interface-Typen manuell deklarieren zu müssen (der Compiler würde dann aus den Public/Published-Dingen dass Interface automatisch generieren), dann hätte man quasi auch einen GC für diese Objekte.
(über die Technik der Generics eventuell machbar, also wenn Emba das implementiert)

Hmm... vielleicht sowas:

Delphi-Quellcode:

type
  TSomeRefCountedObject = class refcounted (TParentClass) // in dieser Reihenfolge, um analog zu "sealed" und "abstract" zu sein

  end;

Zitat von himitsu:

Zitat von implementation:

Wäre es nicht schön, einfach ein Helperkonstrukt für alle Typen zu haben, statt zwischen Class-, Record und Interface-Helpern zu unterscheiden?

Im Prinzip hast du ja Recht, denn über den Zieltüben ließe es sich ja unterscheiden.
Aber dann wäre es nicht mehr ganz kompatibel zum alten Code.

Wieso? "class helper" und "record helper" könnte für alten Code ja bestehen bleiben. Ansonsten (auch für Klassen und Records) ist einfach nur "helper for" möglich.

Und was ich mir wünsche (und vielleicht auch mal implementieren werde):

• Mehrere Class/Record Helper können für einen Typen gleichzeitig verfügbar sein (müsste vergleichsweise einfach für mich umzusetzen sein, da der Code bereits entsprechend ausgelegt ist )

So... Ende der langen Liste

Gruß,
Sven