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 )

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

[Blup]

Zitat von 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.

Du versteifst dich darauf das Vererbung nur in der Form erfolgen kann, wie diese jetzt realisiert wird. Nämlich das man den Record des Vorfahren nimmt und nur neue Methoden anhängt. Das ist jedoch nur notwendig, wenn man einfache "cast" für Interfaces auf Vorfahren zulässt.

Zitat von himitsu:

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.

Selbst das erwarte ich nicht. Wenn du dir meinen Code anschaust, der Compiler soll praktisch ein komplett neues Interface schaffen. In diesem neuen Interface werden natürlich auch die Methoden einen völlig anderen Index haben. Die Vererbung muss nur bei Zuweisung an Variablen vom Typ der Vorfahren berücksichtigt werden.
Das man Interfaces im nachhinein normalerweise nicht verändert, sollte eigentlich bekannt sein. Das sich auch abgeleitete Interfaces in diesem Fall verändern ist Sinn und Zweck der Vererbung.