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

[shmia]

Zitat von implementation:

Zitat von shmia:

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

[Furtbichler]

Zitat von NamenLozer:

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]

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 )

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

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:

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

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.