Delphi 13 - Ternary Operator

[jaenicke]

Zitat von skybibo:

Aber mal ehrlich muss Delphi die Syntax von anderen Sprachen übernehmen? Wie lange ist Delphi dann noch Pascal?

Ich finde es schon gut, wenn sich eine Sprache weiterentwickelt. Und mit dem Argument hätte man damals auch Generics ablehnen können, deren Syntax und Funktionalität ja auch übernommen wurde.

Wie schon geschrieben gefällt mir die aufgeblähte Pascalsyntax des ternären Operators nicht. Das heißt nicht, dass ich ihn nicht verwenden werde. Aber ich finde die Umsetzung in der Mehrheit der Sprachen besser.

[himitsu]

Nja, im Prinzip nutzt es ja nur die bekannte Syntax, womit es somit überall gleich bleibt, egal ob einzeln oder mitten in einer Berechnung.

Ähnlich sieht es z.B. mit dem CASE in Postgres aus, was ja auch einzeln oder mittendrin genutzt werden kann.




Und das Andere, bei i += 1; gegenüber i := i + 1 fällt es nicht auf,
aber s := s + ' '; oder s += ' '; (wobei ich hoffe die Codoptimierung macht aus Ersten sowieso bereits Letzteres),
also zwei Strings verknüfen und einer Variable zuweisen und dann den alten String wegwerfen, oder den neuen string möglichst inplace an den bestehenden anhängen,
aber besonders bei Längerem hätte es Vorteile:

Delphi-Quellcode:

meinelistenvariable.sonstwo[abcdefghijklmnopq].nochwas := meinelistenvariable.sonstwo[abcdefghijklmnopq].nochwas + 'alleluja';
meinelistenvariable.sonstwo[abcdefghijklmnopq].nochwas += 'alleluja';

Letztes ist nicht nur kürzer ... es fällt auch sofort auf, dass hier Quelle und Ziel identisch sind.

[Frickler]

Zitat von himitsu:

Delphi-Quellcode:

meinelistenvariable.sonstwo[abcdefghijklmnopq].nochwas := meinelistenvariable.sonstwo[abcdefghijklmnopq].nochwas + 'alleluja';
meinelistenvariable.sonstwo[abcdefghijklmnopq].nochwas += 'alleluja';

Letztes ist nicht nur kürzer ... es fällt auch sofort auf, dass hier Quelle und Ziel identisch sind.

Pascal böte ja eine Lösung des Problems. Einfach und übersichtlich. Blöd nur, dass man sie nicht verwenden soll:
with meinelistenvariable.sonstwo[abcdefghijklmnopq] do nochwas := nochwas + 'alleluja'; .

Delphi-Quellcode:

Tsonstwo ist eine Klasse:
var x := meinelistenvariable.sonstwo[abcdefghijklmnopq]; x.nochwas := x.nochwas + 'alleluja';
Tsonstwo ist ein Record:
var x := @meinelistenvariable.sonstwo[abcdefghijklmnopq]; x^.nochwas := x^.nochwas + 'alleluja';
(dieser "richtige Weg" ist mir bekannt)

[himitsu]

Bei deinem Beispiel das ^ einmal vergessen,
oder irgendwann aus dem Objekt einen Record gemacht,
und schon passieren komische Dinge (oder auch nicht).

Somit würden += und Co. also nicht nur kürzeren, sondern auch fehlerunanfälligeren Code ermöglichen.
Gerade für sowas sind Syntaxneuerungen was Schönes, wenn es damit dann auch gleich besser, einfacher und sicherer werden könnte.

Zitat:

sie nicht verwenden soll

Nicht sollen ist nicht ganz richtig. (aus schlechten Erfahrungen herhaus, wird davon gern abgeraten)

Zuerst weil der Debugger oft nicht damit klar kommt und man innerhalb des WITH dann nicht an Variablenwerte einsehen kann.

Sowie es zukünftig Probleme geben könnte, und es dann nicht mehr so funktioniert, wie man es sich mal dachte.
(was bereits mehrmals passiert war, weil z.B. Klassen/Records-Interfaces verändert/erweitert wurden)

Und wenn du einen längeren WITH-Block vor dir hast (hier hatte ich schon einen mit fast 100 Zeilen gesehen, 3 WITH verschachtelt und bei einem 2 Dinge drin)
du selbst nicht mehr erkennen kannst, was von wo kommt.
Ja, inline VAR ist eine geile Möglichkeit. (wir hätten uns früher aber auch über benamte WITH gefreut, also anstatt einer impliziten Temp-Variable, ihr selbst einen Namen geben zu können und den dann zu nutzen)

z.B. im FormCreate ein

Delphi-Quellcode:

//var R: TRect;
with R do begin
  Width := Right - Left;
  Height := Bottom - Top;
end;

Gedacht war also

Delphi-Quellcode:

with R do begin
  {Self.}Width := {R.}Right - {R.}Left;
  {Self.}Height := {R.}Bottom - R.}Top;
end;

bis jemand die eigentlich nette Idee hatte, daß TRect ein Width- und Height-Property bekommt,
es plötlich zu dem wurde

Delphi-Quellcode:

with R do begin
  {R.}Width := {R.}Right - {R.}Left;
  {R.}Height := {R.}Bottom - R.}Top;
end;

und man sich wunderte, warum die Form ihre Größe nicht mehr verändert, wenn mit neuen Delphi kompiliert.

Dafür geht es jetzt so, gleich viel besser:

Delphi-Quellcode:

{Self.}Width := R.Width;
{Self.}Height := R.Height;

// oder
{Self.}BoundsRect := R;

[Stevie]

FreePascal kann das https://www.freepascal.org/docs-html/ref/refsu52.html

[DevidEspenschied]

Der ternäre Operator war über Jahre hinweg eines der häufigsten angefragten Spracherweiterungen, und mit RAD 13 wird er nun endlich umgesetzt.

Gleichzeitig ist er optional und man "kann" ihn verwenden, muss aber nicht.

Auch das Argument mit "IfThen" möchte ich kurz ansprechen. Denn "IfThen" wertet alle Parameter aus (das ist relevant!) und nicht nur die notwendigen Parameter, hat gleichzeitig eine eingeschränktere Typzuordnung (und erfordert unterschiedliche uses-Anweisungen, um Funktionen für verschiedene Typen zu finden), funktioniert nicht für so viele Datentypen, ist ein zusätzlicher Funktionsaufruf usw...

Daher würde ich den ternären Operator als wertvolle Spracherweiterung für Object Pascal betrachten, worüber man natürlich mit Pro/Contra diskutieren kann.

Wer mehr wissen möchte, darf sich gerne die Kommentare im englischen Blog (https://blogs.embarcadero.com/coming...elphi-language) durchlesen, wo Ian Barker viele Punkte im Detail beantwortet hat.

[Uwe Raabe]

Zitat von DevidEspenschied:

Gleichzeitig ist er obligatorisch und man "kann" ihn verwenden, muss aber nicht.

Du meinst optional, nicht obligatorisch, oder?

[Samorion]

Also ich freue mich über den Ternary Operator; als jemand, der von anderen Sprachen kommt.

Verstehe allerdings, wieso es manche gibt, die dagegen sein könnten (Wie man im Blogpost ja auch sieht)

[DevidEspenschied]

Zitat von Uwe Raabe:

Du meinst optional, nicht obligatorisch, oder?

Natürlich.

@Samorion: das Thema ist halt grundsätzlich, dass du als Compilerhersteller ständig Kritik bekommst, und man es nicht jedem Entwickler gerecht machen kann. Das ist ein langfristiges Problem, das sich nicht beheben lässt. Daher empfehle ich, sich die Spracherweiterung in Ruhe anzuschauen, sie auszuprobieren, und dann für sich und seine Projekte die Vorteile und Nachteile abzuwiegen.

[Bbommel]

Hm, ich traue mich auch mal mit meiner offenbar "unpopular opinion" aus dem Loch und muss sagen, dass ich das neue Feature ziemlich cool finde. IfThen hat mir nie so gefallen, die Gründe wurden hier mittlerweile alle genannt.

Und auch die Syntax finde ich, so wie sie vorgeschlagen ist, eigentlich okay, weil sie für mein Empfinden gut zur sonstigen Delphi-Syntax passt. Wir nutzen ja auch sonst keine/kaum kryptische Kurzschreibweisen, und so finde ich es dann auch hier gut, vor allem für die Lesbarkeit, dass man die Schlüsselworte if, then und else ausschreiben muss.

Dass es andere Punkte, vor allem Compiler-Bugs, gibt, die vielleicht noch dringender wären als neue Features, kann ich gut verstehen. In einer idealen Welt sollte man natürlich das eine tun, ohne das andere zu lassen.