Was würdet ihr von einem try-except-finally-Konstrukt halten?

[Uwe Raabe]

Zitat von Codehunter:

Anonyme Prozeduren sind nicht per se schlecht, fördern aber schlechten und unübersichtlichen Code. Quasi das Wasser zum Kochen von Spaghetticode.

Das ist aber jetzt das klassische Gegenbeispiel! Was du mit dem Wasser kochst, entscheidest ja nur du allein. Wenn du keinen Spagghetticode willst, dann koch in dem Wasser doch was anderes.

So wie mit jedem Tool kann man auch mit Anonymen Methoden schlechten bzw. schwer lesbaren Code schreiben. Wer sowas macht, braucht dazu aber vermutlich auch gar keine Anonymen Methoden, der kriegt das auch so hin. Dinge nur deswegen zu verteufeln, weil manche damit nicht richtig umgehen können, ist meiner Meinung nach auch nicht zielführend. Besser wäre es, den richtigen Umgang damit zu vermitteln - auch wenn das vielleicht nicht bei allen gelingt.

[Codehunter]

Sagen wir mal so: Ich habe schon sehr früh angefangen, Quellcodes nicht nur für mich zu schreiben sondern auch anderen zu zeigen. Daraus bekommt man viel Feedback zum Thema Lesbarkeit (deswegen ich es auch gut finde dass es jetzt die Delphi CE mit RTL- und VCL-Sourcen gibt).

Wenn ich aber Fremdcode sehe, der von Berlin nach Potsdam über München, Hamburg, Stuttgart, Dresden und Düsseldorf fährt, dann ist mir das ein Graus. Davon gibts für mich nur noch eine Steigerungsform, nämlich wenn mich Sprach- bzw. Syntaxeigenschaften selbst zu solchen Umwegen zwingen.

[himitsu]

Erstmal muß natürlich sowohl try-finally-except-end als auch try-except-finally-end oder gar sowas wie try-finally-except-finally-end usw. möglich sein,
aber das problem dabei ist, dass wohl im TRY der Exception-Block mehrmals bei der CPU registriert/initialisiert werden muß, für jedes einzelne finally/except, damit sowas funktioniert.

Und ja, "named-with" wäre mal was, aber wichtiger wären mir denn doch eher named-arguments und dass bei gewissen Dingen die unverständlichen, nervigen und total unnötigen Reihenfolgezwänge bei der Definition entfallen.
Also sowas wie es teilweise in einigen/vielen C-Sprachen schon ähbliches gibt.
z.B. wo man beim Funktionsaufruf die Namen der Parameter nutzt und dann Parameter auslassen kann,
bzw. bei den assoziative-Arrays, wo Name und Value besser übergeben werden kann und wie es z.B. beim Befüllen von Record-Konstanten kennt, wobei ich es da manschmal schön fände, wenn man dort die Namen weglassen kann, wenn alles übergeben wird, bzw. wenn es Anhand der Reihenfolge eh zuordnen kann, so wie bei Funktionsaufrufen mit Defaultparametern.
Und wieso kann sich der Compiler nichtmal eine Sekunde lang was merken und brauch stdcall, static, virtuell usw. immer in einer bestimmten aber unmerkbaren Reihenfolge?

Delphi-Quellcode:

array of record = (
  (name: "Mantel",   size: [44,42,40,38], price: 69),
  (name: "Jeans",    size: [44,42,], price: 59),
  (name: "Pullover", size: [42,40,38], price: 29),
  (name: "Jacke",    size: [44,42,40], price: 28)
);

MyFunction(ParamA: 'dsad', ParamB: 123); oder zumindestens sowas direkt für Assoziative-Array-Parameter ähnlich dem array of const .


Auch die Variadic-Arguments könnte man in Pascal mal ordentlich einbauen, denn direkt nutzen kann man sie nur bedingt, zumindestens Aufruf und Deklaration innerhalb der eigenen EXE (es geht, sogar sehr einfach und ohne den Compiler zu verbiegen, aber ich garantiere, dass es niemand nutzen will) und das schlimmste sind die fehlenden TypeInfos (liegt aber nicht an Pascal, was aber kein Grund wäre das nicht zu erweitern) und dass der Compiler die falschen Typen verwendet.
z.B. legt C++ Float-Konstanten als Double auf den Stack, aber Delphi als Single, was ohne manuellen TypeCast oder Temp-Variable nicht nutzbar ist um sowas z.B. in einer C++-DLL aufrufen zu wollen, denn durch die fehlenden TypeInfo kann die Funktion nicht drauf reageren und knallt somit gnadenlos gegen die Wand.

[Codehunter]

Ob und wie oft etwas bei der CPU registriert werden muss, genau dafür ist ja der Compiler zuständig. Nachdem man 64 Bit, Unicode und Generics implementieren konnte, dürfte so eine kleine Änderung in die Kategorie "Popelkrams" fallen

Ein benanntes with wäre zumindest nicht mein Wunsch, ich hätte aber auch nichts dagegen solange ich es nicht verwenden muss ^^

Die Idee mit den Record-Initialisierungen während der Deklaration finde ich hingegen sehr gut. Im Moment hat man da oftmals Doppelstrukturen. Einmal die Deklaration oben und einmal die Initialisierung irgendwo unten. Gut man könnte sagen, dafür ist der initialization-Abschnitt ja explizit gedacht. Aber warum zum Geier muss der dann explizit NACH dem implementation-Abschnitt kommen? Und warum das Highlander-Prinzip (Es kann nur einen geben)?

Nachdem man mittlerweile innerhalb von Klassen wiederum lokale Typdeklarationen machen kann (was ich auch ganz gerne nutze der Übersichtlichkeit halber), wirken so manch andere Beschränkungen inzwischen irgendwie altbacken und überholt.

Das Thema array of const kommt anscheinend immer wieder hoch. Die Format-Funktion ist aber m.W. die einzige Stelle wo sowas überhaupt verwendet wird. Vermutlich weil Pascal als streng typisierte Sprache erfunden wurde und das dem Prinzip entgegen läuft ^^

[himitsu]

Zitat von Codehunter:

Ob und wie oft etwas bei der CPU registriert werden muss, genau dafür ist ja der Compiler zuständig. ... dürfte so eine kleine Änderung in die Kategorie "Popelkrams" fallen

one-pass compiler vs. multi-pass compiler
Wenn der Compiler beim TRY noch nicht weiß was nachher alles kommt, dann kann er sowas eben nicht bestimmen.

Jupp, ich habe viele abhängige Typen auch immer öfters als eingebetteter Typ in Klassen drin, genauso wie Konstanten, anstatt sie unten in der Implementation liegen zu haben.
So lassen sich auch interne Typen als PRIVATE einbetten, welche früher global im Interface rumlagen, da sie bereits für Parameter/Results von privaten Methoden und Variablen genutzt wurden.

In Bezug auf Variadic und Assoziative ist in der Sprache Pascal einfach überhaupt nichts vorhanden.
Und es hatte auch einige Jahre gedauert, bis man im Delphi die Property überladen konnte, um das "gleiche" Property mit dem selben Namen z.B. als Index-Integer oder als Name-String ansprechen zu können.

[Codehunter]

Zitat von himitsu:

Wenn der Compiler beim TRY noch nicht weiß was nachher alles kommt, dann kann er sowas eben nicht bestimmen.

Als von CompilernkeineAhnungHaber würde ich sagen, der müsste eigentlich intern nur ein zweites try am Anfang ergänzen und schon müsste das wuppen

Zitat von himitsu:

Jupp, ich habe viele abhängige Typen auch immer öfters als eingebetteter Typ in Klassen drin, genauso wie Konstanten, anstatt sie unten in der Implementation liegen zu haben.
So lassen sich auch interne Typen als PRIVATE einbetten, welche früher global im Interface rumlagen, da sie bereits für Parameter/Results von privaten Methoden und Variablen genutzt wurden.

Erstens das und zweitens verwende ich klassenlokale Enums gerne als Index für Properties mit Gettern und Settern. Wenn man das dann noch mit klassenlokalen Record-Array-Konstanten kombiniert lassen sich sehr elegante Konstruktionen mit wenig Overhead bauen. Sowohl was unnütz überschriebene Methoden angeht als auch die Lesbarkeit vom Code.

[himitsu]

Jupp, der Compiler könnte "einfach" den internen Code für das TRY doppelt einfügen, wenn er denn wüsste, dass nachher zwei finally/except kommen,
aber wenn du den Text nur einmal liest und nicht mal kurz den Blick nach vorne wirfst, dann ist sowas nicht möglich.