Delphi 13 - Ternary Operator

[jaenicke]

Zitat von himitsu:

Ein bissl mehr oder wenigstens etwas Feedback von denen selbst, wäre aber auch nicht verkehrt.

Auch das hilft nicht. Gegeben: Ein großes Projekt, hinter dem eine hohe Summe stand, das sich einfach nicht für Android kompilieren ließ. Ich habe in wochenlanger Kleinarbeit ein Demoprojekt erstellt, per Ticket an Embarcadero weitergegeben, dort ließ es sich auch reproduzieren. Dann blieb das ganze trotz Rückmeldung, dass sich jemand drum kümmert, bis zur nächsten Delphiversion liegen, nur um dann lapidar die Antwort zu bekommen, dass die Demo nun funktioniert. Ja, das stimmte, aber das echte Projekt lief weiterhin nicht. Am Ende standen dann ein eingestampftes Projekt und viel versenktes Geld, weil ich nicht noch einmal so viel Zeit für eine Demo investieren sollte, die dann eh niemand bearbeitet.

Seitdem investiere ich lieber Zeit in Workarounds als in Bugeinträge, weshalb es von mir auch nicht viele gibt. Leider.

Aber das passt nicht in das Thema, von daher zurück zum Thema...

Zitat von dummzeuch:

Eine neue Funktion iif(<condition>, <truevalue>, <falsevalue>), die per Compiler Magic als Ternary Operator fungiert, also anhand der <condition> nur <truevalue> oder <falsevalue> auswertet, wäre sehr wohl möglich gewesen.

Der Übersicht wegen hätte mir das auch gefallen, aber Quelltext, der nach regulärem Funktionsaufruf aussieht, sich aber nicht so verhält, fände ich nicht schön. Das passt nicht zu einer so klar strukturierten Sprache wie Pascal.

[Uwe Raabe]

Zitat von fisipjm:

Funktioniert leider auch nur so semi:

Wieso? Funktioniert doch im Grunde so wie vorher.

[dummzeuch]

Zitat von fisipjm:

Zitat von Uwe Raabe:

Zitat von blawen:

Bedauerlich ist, dass es keine Möglichkeit mehr gibt, einem Anliegen durch ein Upvote mehr Gewicht zu verleihen.

Das soll wohl jetzt über die Kommentare erfolgen.

Funktioniert leider auch nur so semi:
https://embt.atlassian.net/servicede...rtal/1/RSS-526

Das Problem mit dem Refactoring-Modul ist, dass es in J# geschrieben wurde und zwar von einer Firma aus einem der baltischen Staaten (Estland?), die Borland(!) in den 2000ern gekauft hat (soweit ich mich erinnere). Vermutlich hat Embarcadero den Source Code dazu "verlegt", wenn sie ihn je hatten. Die Leute, die es entwickelt haben, sind höchstwahrscheinlich im Laufe der Umstrukturierungen und dem Verkauf der Entwicklertools entlassen worden oder selbst gegangen, so dass heute keiner mehr etwas daran machen kann. Selbst wenn sie das Modul weiterhin mit ausliefern würden, so kann es von der 64 Bit IDE nur sehr aufwändig benutzt werden. Embarcadero muss also wahrscheinlich ein neues Modul entwickeln (lassen) oder eines kaufen. Letzteres ist schwieriger geworden, weil es kaum noch Tool-Hersteller für Delphi gibt und keiner davon ein Refactoring-Tool anbietet, das alles abdeckt, was das bisherige Modul kann. (Mich würde nicht wundern, wenn sie bei Uwe wegen des MMX Code Explorers angefragt hätten, der ist das einzige mir bekannte Tool, das in der Richtung noch übrig ist. Aber auch der deckt nicht alles ab, was das Refactoring Modul kann.)

Ähnliches dürfte für den Code-Formatter gelten. Für den gibt es aber immerhin sogar mehrere Open Source Alternativen (der Code Formatter in GExperts, der in cnPack, der Jedi Code Formatter und der neue in Rust geschriebene pasfmt), die zumindest zum Teil besser funktionieren als der der IDE. Da könnte sich Embarcadero z.B. für einen entscheiden und dessen Entwicklung unterstützen. Kaufen können sie keinen davon, weil die Open Source Lizenzen das nicht zulassen bzw. zu viele unterschiedliche Entwickler daran beteiligt sind/waren, die alle zustimmen müssten (bei GExperts sind es mehrere Dutzend, von denen ich keine Kontaktadressen habe und die teilweise sogar schon verstorben sind). Mich hat Embarcadero deswegen nicht kontaktiert (und wenn, dürfte ich vermutlich nicht darüber sprechen).

Wir werden sehen, was passiert, denn dauerhaft ist der aktuelle Zustand insbesondere mit Blick af die 64 Bit IDE nicht haltbar.

[Uwe Raabe]

Zitat von dummzeuch:

(und wenn, dürfte ich vermutlich nicht darüber sprechen)

Ach was! Nicht?

[himitsu]

Zitat von jaenicke:

Auch das hilft nicht.

Jupp, auch ich hatte schon tagelang gesucht und ein Demoprojekt erstellt.
Am Ende sogar die Lösung geliefert, welches sie in nichtmal 2 Minuten hätten beheben können. (es müssen nur zwei Variablen auf 0 gesetzt werden, bei Zuweisung eines anderen Property)

Emba hat sich geweigert und am Ende haben bei uns 4 Mitarbeiter über eine Woche verschwendet, um einen Bugfix zu bauen. (weil der Fix nicht nur im Kompilat, sondern auch im FormDesigner rein mußte)

[TBx]

Hmmm … und was hat das nun mit dem Ternären Operator zu tun?

Back to topic, bitte

[himitsu]

Ob es verschwendete Lebenszeit ist, mal nach += , -= , *= und /= zu fragen? (auf für Enums, Strings und Arrays)

[jaenicke]

Zitat von himitsu:

Ob es verschwendete Lebenszeit ist, mal nach += , -= , *= und /= zu fragen? (auf für Enums, Strings und Arrays)

Wenn das dann syntaktisch ähnlich dem ternären Operator umgesetzt würde, würde es nichts bringen.

[skybibo]

Zitat von himitsu:

Ob es verschwendete Lebenszeit ist, mal nach += , -= , *= und /= zu fragen? (auf für Enums, Strings und Arrays)

müsste += dann nicht eventuell +:= sein?

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

[himitsu]

Wäre das nicht zuviel des Guten.

Auch so wäre es bereits mit der PascalSyntax kompatibel.

Und warum nicht?


Andere haben bei Delphi Pascal abgeguckt und Pascal hat auch schon viel abgeguckt.

Wenn ich nur an den Mist mit TMonitor denke, oder an TPath ... Umbenannen dürfte man gern mal, bevor es eingebaut wird, wenn es Konflikte geben wird.