Neue Funktionen/Methoden der RTL etc finden

[Dennis07]

Ich habe mir einen Datenbank-Mapper für Code geschrieben, der alle Units analysiert und Funktionen, Klassen und Typen in eine Datenbank schreibt. Aktuell läuft das zwar nur in Testumgebungen, da nicht alles (wie zB. Generics oder variante Records) unterstützt wird, aber irgendwann werde ich es mal hier posten.
Damit kann man das dann sehr leicht machen, zumal es eine eigenst dafür entworfene Query-Language gibt.

[Rudy Velthuis]

Zitat von Uwe Raabe:

Klar ist das natürlich nur dann halbwegs effizient machbar, wenn man jede neue Version auch installiert und möglichst auch einsetzt.

Ich mache das auch (und andere wohl auch), aber wie gesagt, das hilft nicht bei einem großen Sprung, wie von z.B. Delphi 7 nach Delphi 10.3. Da wird das ziemlich schnell unüberschaubar.

[Stevie]

Zitat von Schokohase:

Durch die stellenweise fehlende Dokumentation kann man teilweise gar nicht sagen, ob es sich wirklich um einen Bug handelt oder ob es so gewollt war.

Das ist doch gerade der Trick! Kannste Issues immer fein mit "as designed" abtun

[mkinzler]

Zitat:

Das ist doch gerade der Trick! Kannste Issues immer fein mit "as designed" abtun

Das könnte leider Stimmen.

[Uwe Raabe]

Zitat von Stevie:

Das ist doch gerade der Trick! Kannste Issues immer fein mit "as designed" abtun

Allerdings hätte man bei Existenz einer entsprechenden Doku aber auch keine wirkliche Handhabe. Ich habe oft genug erlebt, daß in einem solchen Fall die Dokumentation angepasst wurde. Der Inhalt des Handbuchs (in dem Fall war es das eines Autos) beschreibt nämlich nicht die zugesicherten Eigenschaften.

[Rollo62]

Das ist ja erschreckend, wo soll das denn sonst festgelegt werden, etwa in den Verkaufsunterlagen ?

Aber Du hast wahrscheinlich Recht, denn um das rechtssicher zu machen müsste im Kaufvertrag
"Kaufverträg über Kfz gemäß der zugesicherten Eigenschalten lt. Handbuch Rev. 1.0" stehen.
Dann wäre das wohl bindend.

Wenn das Manual nicht zuständig wäre müsste man wohl alle Eigenschaften im Kaufvertrag einzeln aufzählen:
"Kaufverträg über Kfz mit 5 Gängen, Aschenbecher vo/hi.li/hi.re, Handschuhfach, mit Antenne, ...

Das kann es doch auch nicht sein

[Uwe Raabe]

Das ist ja generell das Problem bei Software: Gäbe es eine umfassende und vollständige Spezifikation, könnte man das auch verifizieren. Aber wann hat man sowas schon.

Vermutlich ist die einzig haltbare Zusicherung bei Software, daß die CI-Testsuite durchläuft. Aber wer kann schon alles und in jeder denkbaren Kombination testen.

[Stevie]

Zitat von Uwe Raabe:

Das ist ja generell das Problem bei Software: Gäbe es eine umfassende und vollständige Spezifikation, könnte man das auch verifizieren.

Das Thema hier sind RTL Funktionen, und die kann man sehr wohl sehr genau spezifizieren und verifizieren - und auch Abgrenzungen wie "für Input x, y, z ist das Verhalten undefiniert".
Weil man das aber nicht tut, entstehen immer wieder Defekte, wenn irgendwas refactored wird.

Beispiel: https://quality.embarcadero.com/browse/RSP-13021

Siehe Dokumentation: http://docwiki.embarcadero.com/Libra...per.StartsWith

Vergleich mit .NET Standard: https://docs.microsoft.com/en-us/dot...etstandard-2.0

[Uwe Raabe]

Zitat von Stevie:

Das Thema hier sind RTL Funktionen, und die kann man sehr wohl sehr genau spezifizieren und verifizieren

Da bin ich voll auf deiner Seite. Mein Einwand bezog sich auch nicht auf die Möglichkeit einer vollständigen Spezifikation grundlegender Funktionen und deren Mehrwert, sonder eher auf die real existierende Unvollständigkeit derselben. Insbesondere würde das auch einige Fälle von Diskrepanz zwischen Erwartungshaltung und Intention auflösen.

Manchmal ist es zwar ganz spannend vollständig undokumentierte Funktionalität in RTL oder VCL zu analysieren, besonderes effizient ist das allerdings nicht.

[TigerLilly]

Da war doch einnmal etwas:

http://www.nickhodges.com/post/The-D...t-Project.aspx