EMB DCE 12 - Bedingungen mit einen Assign-Zeichnen

[QuickAndDirty]

Zitat von Uwe Raabe:

Um solche mehrzeiligen Conditions besser les- und wartbar zu machen, bieten sich separate function <sinnvoller Name>(...): Boolean an. Um die Performance nicht zu sehr zu beeinträchtigen, kann man die dann ja inline deklarieren.

Compile Time Makros wären mir noch lieber.

[himitsu]

Wird von Emba abgelehnt.

Schon mehrfach danach gefragt.
Und dabei hab ich sogar eine für die Pascal-Syntax passende Variante für einfache einzeilige Makros vorgeschlagen.

Leider ist es auch nicht mehr möglich einen "Precompiler" zwischenzuschalten, so, wie es jemand bis Delphi 7 genutzt hatte.

[QuickAndDirty]

Compiletime Makros würden auch sowas bedingte generics abbilden können oder Ducktyping... Ich fände das schon ganz praktisch... besser als inlining.

[himitsu]

Ducktyping ist in Pascal schon möglich (wurde in mehreren Projekten umgesetzt, brutal mit OleVariants und Interfaces),
aber auf CodeCompletion, CodeInsight, HelpInsight und derartig nutzloes Zeugs, darf man dabei verzichten.
Auch fallen Schreibfehler erst zur Runtime auf.

[jaenicke]

Zitat von himitsu:

Ducktyping ist in Pascal schon möglich (wurde in mehreren Projekten umgesetzt, brutal mit OleVariants und Interfaces)

Da gefällt mir das Konzept für Duck Typing bei Oxygene besser. Aber ja, sowas habe ich auch schon verwendet...

[himitsu]

Ich bastel da grad an was mit Managed-Custom-Records ... funktioniert eigentlich ganz gut, auch wenn hier Scriptsprachen mit ihrer typlosen Art mehr Möglichkeiten haben, was so in Delphi garnicht möglich ist.

Bzw. Einwas würde ich auch in Delphi hinbekommen, aber dafür sind dann hunderte generische Records/Klassen nötig, um 2 Records/Klassen "dynamisch" und über mehrere Levels zu kombinieren (ohne bei Benutzung immer manuell casten zu müssen) .... das würde keinen Spaß machen und hab ich mir gespart erspart,
Welches mit autocasts in Scriptsprachen sofort von alleine ginge.

Zitat:

Duck Typing bei Oxygene

Ahhh, Oxygene war's .... ein Kollege hatte mir da vor Jahren mal was gezeigt (glaub grade das war von dort ... das mit den OleVariants)

In Delphi hast du sowas aktuell beim JSON-Builder, aber das Ding ist ekelhaft und an (mindestens) einer Stelle unpraktisch (nicht schön benutzbar).

[jaenicke]

Zitat von himitsu:

Ahhh, Oxygene war's .... ein Kollege hatte mir da vor Jahren mal was gezeigt (glaub grade das war von dort ... das mit den OleVariants)

Nein, da funktioniert das viel besser. Du castest auf duck<T> und kannst dann direkt mit diesem Typ arbeiten. Inklusive Syntaxergänzung usw. und mit soft interfaces brauchst du noch nicht einmal den Cast.

[himitsu]

Zitat:

smart interfaces .......

Jupp, dass ist des Problem.
Die Codevervollständigung ist dann weg.

OK, als wenn die aktuell eh überhaupt meistens funktionieren würde (wenn man den LSP nicht minütlich neu startet)

[jaenicke]

Zitat von himitsu:

OK, als wenn die aktuell eh überhaupt meistens funktionieren würde (wenn man den LSP nicht minütlich neu startet)

Tatsächlich habe ich mittlerweile mehrere größere Projekte gesehen und beraten und eins selbst entsprechend bearbeitet, damit der LSP besser funktioniert. Wenn man z.B. Kreuzreferenzen und with entfernt, funktioniert der LSP in der Regel echt gut und relativ schnell. Und wenn man z.B. noch bei Delphi 10.4 ist, muss man auch auf Inline-Variablen verzichten. Klar, da ist noch viel Luft nach oben und es ist natürlich echt doof, dass es nicht einfach mit jedem Quelltext funktioniert, aber ich bin schon froh, dass es mit sauberen Quelltexten gut klappt.

Aber das ist ein anderes Thema.

[himitsu]

Du könntest ja Emba beraten, damit es von der Seite mal besser funktioniert.

Manchmal könnten sie den LSP auch selbst neu starten ... oft muß Delphi doch selbst merken, dass der hängt.
z.B. wenn die Codevervollständigung nur 2 Einträge hat, dann muß doch klar sein, dass des nicht stimmen kann.