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

**Namenloser**

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
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.
Ich fände es außerdem cool, wenn sowas ginge: 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.
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. myString[3:5] statt 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...

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 von Furtbichler:

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

markieren

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

- Delphi-Referenz durchsuchen

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

)

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

- 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

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

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

**Namenloser**

Zitat von himitsu:

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

- Interface Helper

Achja genau, das hatte ich noch vergessen. Ich wäre einfach für einen allgemeinen Helper , für jeden Typ, egal ob Klasse, Record oder primitiver Datentyp wie Integer. Diese Unterscheidung von class helpern und record helpern ist redundant, weil der Datentyp, auf den sich der Helper bezieht, ja ohnehin klar ist. Und falls man mal aus einem Record eine Klasse macht oder umgekehrt, müsste man nicht auch noch zusätzlich alle Helper-Definitionen anpassen.

zusammenfalten · markieren

Delphi-Quellcode:

			type

  TFormHelper = helper for TForm

    procedure FadeOut();

  end;

  TRectHelper = helper for TRect

    procedure Normalize;

    function ContainsPoint(Pt: TPoint): Boolean;

  end;

  TIntHelper = helper for Integer

    function ToString: string;

  end;

Damit wären sehr moderne Konstrukte und modulare Programmierung möglich.

**implementation**

Na das sind ja schonmal einige Punkte

Zitat von himitsu:

markieren

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:

markieren

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:

markieren

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

)

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

Zu allem unkommentierten: Full Ack

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

Zitat:

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

Ein Operator Helper

Für Objekte sind Operatoren leider nicht möglich, der fehlenden automatischen Speicherverwaltung wegen,
aber wenn man die Copy/Create/Destroy-Ereignisse einführt, würde es dennoch einen Weg geben.

**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!

markieren

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.

**implementation**

@Medium:

Das ist eine verdammt gute Idee! Was mich an GC-Sprachen bisher insbesondere gestört hat, war, dass man den GC nicht einfach abstellen konnte. Ich habe über eine Hybridschiene schon nachgedacht, aber da bin ich immer zur Kollision gekommen.
Der Einfall, die Objekte einfach durch einen anderen Konstruktor zu erzeugen ist ein genialer Ansatz.

Das wäre allerdings ein Punkt, den ich allein nicht umsetzen könnte, weil ich a) von GC-Bau keinen Schimmer habe und b) auch keinen kenne, den man zu dem Zweck in die Ausgabedatei einfach automatisch einbinden könnte.
Die bisherigen Punkte würde ich mir zutrauen, aber ein Hybrid-GC ginge über meine Fähigkeiten hinaus.

**himitsu**

Zitat von Medium:

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.

Wenn du jetzt noch sicherstellst, daß es nirgendwo "Altprogramme" gibt, wo z.B. "new" als Variable/Typ/Konstante/Parameter/Feld/... existiert, dann wäre das möglich.

Ansonsten hast du ein Problem, da plötzlich aus Diesem ein "reserviertes" Wort werden würde.
In Delphi also nicht möglich, obwohl es auch ohne GC technisch möglich wäre, wenn man den "new"-Operator auf die ".Create"-Constructoren umleitet.

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)

Über einen Precompiler könnte ich sowas auch selber nachrüsten.