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

[shmia]

Zitat von implementation:

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:
destructor Destroy;override; Jeder Abweichung von dieser Deklaration führt zu einem nicht funktionierenden Destruktor.

[implementation]

Danke schonmal für dein Feedback!

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

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