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

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

[Codehunter]

In wie weit unterscheidet sich das Problem von einem if-elseif-else?

EDIT: In gewisser Weise voraus schauen muss der Compiler doch jetzt auch schon. Denn sonst wüsste er doch nicht, ob das try nun von einem finally oder einem except abgeschlossen wird.

[Delphi-Laie]

Zitat von Codehunter:

Was haltet ihr davon?

Sehr viel!

Ich muß gestehen, daß mir die Erklärungen der verschiedenen try....-Konstrukte unvollständig erschienen, ja, das behinderte sogar mein Verständnis derselben. Mir leuchtete z.B. nie ein, warum eine eventuell auftretende Ausnahme, deren Behandlung mit "except" eingeleitet wird, nicht manche Situationen nach sich zieht (ziehen kann), in denen sichergestellt werden muß, daß bestimmte Operationen auch bei Auftreten einer Exception vollständig abgeschlossen werden (mit "finally" eingeleitet").

Die Lösung ist so (")einfach("), nämlich die Kombination (Verschachtelung) beider. Das fand ich erstmals in einem Delphi-Buch und hier nun auch wieder. Das mag zwar recht flexibel sein, doch es wirkt aufgebläht, gestelzt, konstruiert bzw. "gebastelt".

Warum die Entwickler dieser komfortablen Hochsprache das nicht besser gelöst haben (lösen konnten?), ist mir rätselhaft. Vielleicht liegt es aber auch nur an meinem mangelhaften Verständnis, und es geht eben nicht besser.

[TurboMagic]

Zitat von Codehunter:

Ich würds ja gerne als Feature Request an Emba schicken, aber auf der Loginseite der Quality Central komme ich nicht weiter. Überall kann ich mich mit meinem EDN-Account einloggen nur auf dieser Seite nicht:

Zitat:

Sorry, an error occurred trying to log you in - please try again.

Tja, normalerweise funktioniert das. Was hast du als EDN account genommen? Den Benutzernamen oder die E-Mail Adresse? Ich nahm den benutzernamen und lkann fröhlich Feature Requests und Bugreports ins System eingeben...
Ggf. mal versuchen deine EDN Kontodetails zu finden, weil dort sicher irgendwo der Benutzername drin steht. Falls das alles nichts hilft EMBT support kontaktieren. Wenn nicht klar ist über welche E-Mail Adresse dann nochmal melden, ansonsten die Reportnummer hier melden. Dann können wir abstimmen und den Report beobachten.

Grüße

TurboMagic

[Codehunter]

Benutzername und Email ging beides nicht. Ich hatte gestern Matthias deswegen eine PM geschrieben. Heute früh gings dann. Ob was geändert wurde an meinem Account oder ob das ein technischer Fehler war, keine Ahnung.

Jedenfalls ist das jetzt online als AP-225. Mit meinem bescheidenen Englisch versteht sich

[Uwe Raabe]

Zitat von Codehunter:

Jedenfalls ist das jetzt online als AP-225.

Wäre das nicht besser im Projekt RAD Studio aufgehoben, anstatt in dem bereits wieder eingestellten AppMethod?