![]() |
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
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) );
Delphi-Quellcode:
oder zumindestens sowas direkt für Assoziative-Array-Parameter ähnlich dem
MyFunction(ParamA: 'dsad', ParamB: 123);
Delphi-Quellcode:
.
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. |
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
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 ^^ |
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
Zitat:
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. |
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
Zitat:
Zitat:
|
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
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. |
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
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. |
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
Zitat:
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. |
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
Zitat:
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 |
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
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 ![]() |
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
Zitat:
|
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
Zitat:
|
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
Zitat:
|
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
Zitat:
|
AW: Was würdet ihr von einem try-except-finally-Konstrukt halten?
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:15 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz