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

[implementation]

Hallo liebe Delphisten,

im Laufe der Zeit haben sich bei mir einige Dinge angehäuft, die mich an der aktuellen Syntax von Object Pascal stören.
Darunter sind folgende:

• 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.
• 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
• Methoden und nichtmethodische Routinen sind im implementation-Teil sprachlich nicht gruppiert (höchstens durch Kommentare)
• 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?

Daher habe ich mir mal einen Entwurf für einen neuen kleinen Dialekt überlegt, der diese Dinge besser machen soll, ich nenne ihn bisher "Thrym".

Hier mal ein Ausschnitt:

Delphi-Quellcode:

// Thrym

unit sample;

// Uses-Klausel außerhalb von public/private/implementation
uses
  ...

// public + private statt interface
public

  type
    TExample = class
    public
      procedure Sample;
    end;
    
    // Counted Interfaces:
    //   Klassische COM-Interfaces, auf Methoden beschränkt,
    //   Properties gehen den Weg über diese
    //   (Referenzzählung!!)
    IExample = counted interface
      ['{GUID}']
      procedure SetTest(AValue: Integer);
      function GetTest: Integer;
      property Test: Integer read GetTest write SetTest;
    end;
    
    // Uncounted Interfaces:
    //   Von COM komplett unabhängig, keine Referenzzählung
    //   Properties müssen nicht direkt einen Getter/Setter
    //   zugewiesen bekommen, dies ist Sache der Implementierung
    //   Implementierende Klassen müssen nicht AddRef/Release/
    //   QueryInterface unterstützen
    ISample = uncounted interface
      property Test: Integer read write;
    end;
    ...
  
  const
    ...
    
  var
    ...
    
private

  type
    // Schema-Typ, wie in GPC:
    TCharArray(start, length: Integer) = array [start..start+length] of char;
    TSample = TCharArray(0,6);
    ...
    
  const
    ...
    
  var
    ...
    FProp: Integer;
    
// können auch mehrere public/private sections sein
public

  // z.B. um global properties besser zum ermöglichen
  property Prop: Integer read FProp write FProp;
  
implementation // oh, it's me!

  // In den Implementation-Teil kommt
  // tatsächlich nur noch die Implementierung
  // der im public- und private-Teil deklarierten
  // Methoden und nichtmethodischen Routinen

  // Methoden gruppieren nach Klasse
  TExample: begin
  
    procedure Sample;
    var obj: TExampleObject;
    begin
      obj := TExampleObject.Create;
      try
        // Do Something
      finally
        // den Destruktor gefahrenlos direkt aufrufen können
        // damit benannte Destruktoren auch endlich wieder Sinn
        // machen - wozu kann man sonst mehrere Destruktoren
        // deklarieren, wenn man eh nur Destroy über Free verwenden
        // kann
        obj.Destroy;
        // schön wäre es jetzt noch, wenn obj gleich auf Nil gesetzt würde
        // dazu aber dick: Fragezeichen ?
      end
    end;
  
  end;

end.

Nun möchte ich das ganze aber nicht einfach verschlimmbessern, daher Frage an euch: Was haltet ihr von diesen Änderungen, insbesondere dem automatischen nil-setzen?

Je nach Feedback setze ich das ganze vllt. in Zukunft mal durch einen Präcompiler um, der dies dann in FreePascal-Code oder Delphi-Code umschreibt.

Verbesserungsvorschläge, Kritiken und Featurerequests sind gern willkommen (dazu mache ich den Thread ja auf :stupid:)

[shmia]

Zitat:

Zitat von implementation (Beitrag 1145448)

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?

Ein Klasse kann grundsätzlich nur einen Destruktor haben.
Es mag verschiedene Arten geben ein Objekt zu erzeugen aber es gibt nur eine Art es zu zerstören.
Das gilt IMHO für alle OO Programmiersprachen.
In Delpi muss der Destruktor immer so deklariert werden:

Delphi-Quellcode:

destructor Destroy;override;

Jeder Abweichung von dieser Deklaration führt zu einem nicht funktionierenden Destruktor.

[implementation]

Danke schonmal für dein Feedback!

Zitat:

Zitat von shmia (Beitrag 1145467)

Jeder Abweichung von dieser Deklaration führt zu einem nicht funktionierenden Destruktor.

Eben das ist ja das, was mich stört. Man kann auch weitere Destruktoren deklarieren, aber die tuns dann nicht so, wie sie sollen.
Was ist, wenn ich eine Objektliste deklarieren will, und zwei verschiedene Destruktoren möchte: Einer, die die Objekte mitfreigibt, und einer, der dies nicht tut. Momentan wäre das auf diese Weise so nicht wirklich machbar.

Wir haben in Object Pascal benannte Destruktoren, wir können sie nur nicht anständig nutzen. Und das stört mich, deshalb möchte ich es in Thrym besser machen.

Zitat:

Das gilt IMHO für alle OO Programmiersprachen.

In den meisten Sprachen kann man Con- und Destruktoren auch nicht benennen.

[shmia]

Zitat:

Zitat von implementation (Beitrag 1145470)

Zitat:

Zitat von shmia (Beitrag 1145467)

Jeder Abweichung von dieser Deklaration führt zu einem nicht funktionierenden Destruktor.

Eben das ist ja das, was mich stört. Man kann auch weitere Destruktoren deklarieren, aber die tuns dann nicht so, wie sie sollen.

Ah ok - da müsste der Compiler doch einfach nur auf jede Abweichung von der richtigen Destruktor-Signatur mit einem Compilerfehler reagieren.
Das Problem von Delphi ist, dass der Destruktor überhaupt einen Namen bekommen hat.
Man hätte das z.B. auch so machen können:

Delphi-Quellcode:

TEineKLasse = class(TBasisKlasse)
...
public
  constructor Create;
  destructor;
end;

destructor TEineKLasse;
begin
  ...
  inherited;
end;

// und statt Destroy oder Free würden man Objekte so freigeben:
Dispose(einObjekt);

[implementation]

Genau, so habe ich mir das zunächst auch gedacht, als mir das Problem bewusst wurde.
Aber warum nicht den "Bug" zum Feature machen ;)
Im oben erwähnten Beispiel mit der Objektliste hielte ich es für sehr sinnvoll, zwei verschiedene Destruktoren zu haben.


Das zweite Destruktor-Problem ist, dass man ihn nicht direkt aufrufen sollte, weil's Crash geben kann. Und was macht man da? Dem Destruktor die gleiche Funktionalität der Free-Methode geben, ist mein bisheriger Vorschlag.

[EDIT] Ah, jetzt erst das Dispose bei dir gesehen. Das ist auch ein sehr guter Vorschlag, da hätte man es gleich einheitlich mit Pointern.

[Namenloser]

• Ich finde, man sollte Variablen immer bei der Deklaration initialisieren können, also nicht nur globale Variablen, sondern auch Felder und lokale Variablen.
  Delphi-Quellcode:

  var x: integer = 0

• 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.
  Delphi-Quellcode:

  if a<b and b<c then ...

  statt
  Delphi-Quellcode:

  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.
• Ich fände es außerdem cool, wenn sowas ginge:
  Delphi-Quellcode:

  if a < b < c then ...

  . Ich glaube Prism/Oxygene kann das.
• Hin und wieder nervt mich, dass man im Interface-Bereich Felder immer vor Methoden deklarieren muss.
• Delphi-Quellcode:

  try ... except ... finally ... end

  statt zwei try-Blöcke schachteln zu müssen.
• Fände es manchmal cool, wenn man, wie in einigen Scriptsprachen, Bereiche von Arrays direkt per Sprachfeature herauskopieren könnte. Z.B.
  Delphi-Quellcode:

  myString[3:5]

  statt
  Delphi-Quellcode:

  Copy(myString, 3, 2)

  .
• Strings sollen gefälligst bei 0 anfangen wie ein anständiges Array, nicht bei 1!

Das fällt mir jetzt spontan so ein...

[Furtbichler]

Zitat:

Zitat von NamenLozer (Beitrag 1145507)

Strings sollen gefälligst bei 0 anfangen wie ein anständiges Array, nicht bei 1!

Das würde ich noch nicht einmal vorschlagen. Stell Dir vor, irgendein Guru denkt, das das ne gute Idee ist und führt es mit XE 4 ein... DAS wird lustig.

Ansonsten ist Delphi leider veraltet und hinkt. Das Handicap wird es auch nicht wieder los.

[Namenloser]

Zitat:

Zitat von Furtbichler (Beitrag 1145515)

Das würde ich noch nicht einmal vorschlagen. Stell Dir vor, irgendein Guru denkt, das das ne gute Idee ist und führt es mit XE 4 ein... DAS wird lustig.

Ansonsten ist Delphi leider veraltet und hinkt. Das Handicap wird es auch nicht wieder los.

Geht ja auch nicht um ernsthafte Wünsche für die Delphi-Language – klar, das wird man die Altlasten nicht mehr los. Aber das Thema heißt ja auch „Vorschläge für einen neuen Dialekt“.

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

Was ich mir aber wünschen würde:
- 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)

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

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

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

- Interface Helper

- Operatoren für Interfaces

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

- 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

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

- ein Continue und Break mit Ebenenangabe, so daß man mehrere Schleifen unterbrechen kann

- manchmal (ganz selten) hab ich mit schon eine kombinierte Try-Except-Finally-Stuktur gewünscht

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

- string aus den reservierten Wörtern rausnehmen

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

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

- uvm.


Also nur Neuerungen/Verbesserungen, welche aber nicht die "alte" gewohnte Syntax beeinflussen




- eine bessere Informationspolitik seitens Emba, endlich mal eine ordentliche Emba-Webseite erwähn ich besser mal nicht :stupid:

Zitat:

Strings sollen gefälligst bei 0 anfangen wie ein anständiges Array, nicht bei 1!

Gut, das wäre mal praktisch, aber für Delphi leider nicht mehr möglich :oops:



Das zu den störenden Elementen und wenn, dann darf man das gerne auch in einer neuen Syntax verbauen.

[implementation]

Na das sind ja schonmal einige Punkte :thumb:

Zitat:

Zitat von himitsu (Beitrag 1145518)

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.

Stimmt, sieht hässlich aus, wäre aber quasi die Lösung für:

Zitat:

- die Generics so erweitern, daß man statt typen auch Konstanten verwenden kann.

Vllt. aber dann doch lieber so schreiben:

Delphi-Quellcode:

TIrgendwas<type t; const a,b: Integer> = class
  ...
end;

Zitat:

Class Helper (nicht nur Klassen.Methoden) [...] Record Helper für einfache Basistypen [...] Interface Helper

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

Delphi-Quellcode:

TXyz = helper for ...
  ...
end;

Zitat:

Operatoren für Interfaces

Bei Operatoren finde ich die FPC-/GPC-Syntax ganz schön, sie komplett aus der Klassendeklaration herauszunehmen. Dadurch wird jeder Typ operatorfähig, z.B.:

Delphi-Quellcode:

operator :=(const i: IMyInterface): string;

Zitat:

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

Wie wäre es mit einer Trennung zwischen Record und Union?


Zu allem unkommentierten: Full Ack :thumb: