Neue Funktionen/Methoden der RTL etc finden

[TigerLilly]

Die Frage klingt vielleicht ein wenig schräg: Wie findet Ihr die neuen Funktionen/Methoden, die mit den Updates und Releases hinzukommen?

Ich mach grad einen großen Sprung nach 10.3 und habe immer wieder so "Ah! Oh! das gibt´s ja schon!" Erlebnisse.

Ich kann natürlich den Code durchackern oder mir überlegen, wie die Funktion heißen könnte + suchen.

Konkret zB: Ich habe immer wieder Anweisungen der Form:

Code:

if s<>'' then
   s:=s+' ';
s:=s+'irgendwas';

Dafür hab ich mir eine Funktion gemacht. Aber sowas gibt es wahrscheinlich mittlerweile in der RTL?

Cool wäre eine Suche der Art: "strings, concatenation, separator" oder so.

[Rollo62]

Gar keine blöde Frage, ich versuche auch immer wesentliche Änderungen herauszubekommen.
Irgendwas mit GIT oder Grep Vergleich Alt/Neu ?

Aber so richtig befriedigend ist das nicht.

[Rudy Velthuis]

Zitat:

Zitat von TigerLilly (Beitrag 1431475)

Code:

if s<>'' then
   s:=s+' ';
s:=s+'irgendwas';

Dafür hab ich mir eine Funktion gemacht. Aber sowas gibt es wahrscheinlich mittlerweile in der RTL?

Cool wäre eine Suche der Art: "strings, concatenation, separator" oder so.

In Delphi 10.3 kann man string.Join benutzen: http://docwiki.embarcadero.com/Libra...ingHelper.Join

Aber wenn ich sowas suche, dann nehme ich meine Grep-Anwendung (Greppola) und suche mich durch die Quelltexte im Source-Verzeichnis. Grep ist wesentlch flexibler als eine einfache Suche und man kann auch nach alternativen Suchen, oder andere Schreibweisen.

[Rollo62]

Ein Gedanke wäre mit einem Diff-Tool die C++Header unter \Include zu vergleichen, was es dort an Änderungen/Erweiterungen so gibt.

Leider gibt es nur für sehr wenige Units solche C++ Header.
Evtl. kann man sich die aber für Alles was im Source ist erzeugen lassen, durch Neukompilieren,
aber ich lasse da normalerweise die Finger davon und arbeite mit dem Orginal-EMBA Setup.
So weiss ich wenigstens woher irgendwelche Probleme kommen :stupid:

[Der schöne Günther]

Embarcadero -> DocWiki -> What's New

http://docwiki.embarcadero.com/RADStudio/Rio/en/What's_New

[bernau]

Zitat:

Zitat von TigerLilly (Beitrag 1431475)

Die Frage klingt vielleicht ein wenig schräg: Wie findet Ihr die neuen Funktionen/Methoden, die mit den Updates und Releases hinzukommen?

Das habe ich mich auch schon oft gefragt. Da hilft nur stöbern. Einen ungefähren Ansatz hat man ja. In deinem Fall einfach die "System.StrUtils" öffnen und blättern.

Stöbern mache ich immer wieder. Oft finde ich gar nicht die entsprechende Funktion. Aber ein kleines "Ahhh" und "Ohh" geht mir immer wieder durch den Kopf. Man findet immer wieder eine Funktion, die es beim näheren Hinschauen sogar schon länger gibt und die man vor einiger Zeit selber geschrieben hat. Dann gibt es in meiner Utils-Unit zur Funktion ein "deprecated" und wird mit der Zeit ersetzt.

Stöbern hat auch den Vorteil, dass man auch am Quelltext sich Ideen holen kann. So werden in der RTL immer mehr Funktionen in Records zusammengefasst. z.B. TFile und TDirectory. Damit freunde ich mich immer mehr an und fließt immer mehr in meinen Programmier-Stiel ein.

[Uwe Raabe]

Kein Witz! Ich vergleiche mit jedem Release das Source-Verzeichnis der Delphi-Installation mit dem Vorgänger. Dabei fallen mir dann schon einige Konstrukte und Funktionen ein, die ich nun mit Bordmitteln erledigen kann. Bei der täglichen Arbeit weiß ich dann meistens schon: Moment, da war doch was!

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

Dieses Vorgehen hat noch einen angenehmen Nebeneffekt: Meine Sourcen werden, vorbehaltlich neuer Funktionalitäten, mit der Zeit immer kleiner und damit leichter wartbar.

[dummzeuch]

Ich werfe dafür häufig die Google Suche an. Also eigentlich immer, bevor ich eine neue, nicht triviale aber möglicherweise häufig benutzte Funktion schreibe. Dann finde ich entweder heraus, dass es inzwischen eine RTL-Funktion dafür gibt, oder ich finde irgendwo eine fertige Funktion, die ich verwenden oder ggf. als Grundlage für eine eigene verwenden kann. Meist ist eines der ersten Ergebnisse auf StackOverflow, welches dadurch trotz des inzwischen miesen Klimas dort noch hilfreich ist.

Theoretisch könnte man natürlich auch in der Hilfe suchen, inzwischen ist die ja wieder annehmbar, aber die Suche dort ist einfach weniger bequem als Google-Suche nach

Code:

"delphi" einige Stichworte

Leider rächt es sich dann wieder, dass ich für viele Entwicklungen immernoch auf Delhi 2007 angewiesen bin, denn häufig gibt es neue Funktionen erst in späteren Versionen.

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1431489)

Kein Witz! Ich vergleiche mit jedem Release das Source-Verzeichnis der Delphi-Installation mit dem Vorgänger. Dabei fallen mir dann schon einige Konstrukte und Funktionen ein, die ich nun mit Bordmitteln erledigen kann. Bei der täglichen Arbeit weiß ich dann meistens schon: Moment, da war doch was!

Ja das mache ich auch so.
Ich kann mir aber (aus Zeitgründen) nur die gerade für mich relevanten Teile ansehen.
Wenn ich den TE richtig verstehe geht es ihm (wie mir) mehr um die "header (interfaces)",
um mal grob zu sehen wo es erwähnenswerte Unterschiede gibt, ohne sich erstmal durch alle Units zu wühlen.

Vielleicht müsste man sich ein Tool bauen, was diese Interface-Section Syntax-Tree analysieren, und vergleichen kann (falls es das nicht schon gibt).

[mkinzler]

Es wäre schön, wenn es nicht notwendig wäre, dass wir Kunden nach Änderungen suchen müssen. Aber man bekommt es ja nicht mal hin, dass die Syntaxprüfung (zeitnah) der IDE an die Änderungen angepasst wird.

[Der schöne Günther]

So früh am morgen und schon solche negativen Vibrations im Raum?

[Rollo62]

Zitat:

Zitat von mkinzler (Beitrag 1431495)

Es wäre schön, wenn es nicht notwendig wäre, dass wir Kunden nach Änderungen suchen müssen. Aber man bekommt es ja nicht mal hin, dass die Syntaxprüfung (zeitnah) der IDE an die Änderungen angepasst wird.

Aber mal ehrlich: Das wäre etwas unrealistisch sowas von EMBA zu Verlangen.
Wie oft lege ich neue Funktionen an, wie oft Refakturiere ich meinen Code ...
Jede Änderung zu Dokumentieren würde ich nicht schaffen.

Es sei denn: Das ginge automatisiert :-D
(GIT mit Diff-Tool wäre da mein heimlicher Favorit, der könnte doch eine Change-List auswerfen)

[mkinzler]

Zitat:

Aber mal ehrlich: Das wäre etwas unrealistisch sowas von EMBA zu Verlangen.Wie oft lege ich neue Funktionen an, wie oft Refakturiere ich meinen Code ...
Jede Änderung zu Dokumentieren würde ich nicht schaffen.

Es ist aber ein Unterschied, ob es Dein eigener Code ist oder die offizielle API.
Die (Subscription-)Kosten sind ja auch nicht unerheblich.

[Rollo62]

Naja, mir ist noch lieber EMBA fixt Probleme, statt dass sie Unnötiges dokumentieren.
Wir Reden ja hier von den "kleinen" Unterschieden, nicht der "großen" Roadmap.

[mkinzler]

In Sachen Dokumentation fehlt ja leider mehr als nur ein paar "unnötigen" Details.

[MichaelT]

Stimmt. Unvermutetes mittels Suche zu finden ist eher dem Zufall geschuldet und auch ich habe von Zeit zu Zeit noch so manches Aha-Erlebnis. Klassen zu finden bedingt deren Existenz zu kennen.

Wenn 3 Jahre später eine Klasse wird angeboten die ein 'damals' höchst aktuelles Thema adressiert fehlt einfach der Trigger.

Zitat:

Zitat von mkinzler (Beitrag 1431495)

Es wäre schön, wenn es nicht notwendig wäre, dass wir Kunden nach Änderungen suchen müssen. Aber man bekommt es ja nicht mal hin, dass die Syntaxprüfung (zeitnah) der IDE an die Änderungen angepasst wird.

[Schokohase]

Zitat:

Zitat von Rollo62 (Beitrag 1431503)

Naja, mir ist noch lieber EMBA fixt Probleme, statt dass sie Unnötiges dokumentieren.
Wir Reden ja hier von den "kleinen" Unterschieden, nicht der "großen" Roadmap.

Mir wäre es lieber Emba würde so arbeiten, wie man es mache sollte.

Erst mal einen Plan, was man machen möchte, mit Beschreibung was man zu erwarten hat (das nennt sich z.B. Spezifikation). Damit wäre im Prinzip auch die Dokumentation schon mal fertig.
Jetzt die Implementierung gemäß der Spezifikation/Dokumentation nebst zugehörigen Unit-Tests.

Und ehe man sich versieht ist man wesentlich produktiver weil man weniger Bugs/Probleme produziert.

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.

[Rollo62]

Wir müssen aber mit dem Leben was wir haben, und da ist es realistischer selber im Code nachzusehen.

[MyRealName]

Zitat:

Zitat von TigerLilly (Beitrag 1431475)

Die Frage klingt vielleicht ein wenig schräg: Wie findet Ihr die neuen Funktionen/Methoden, die mit den Updates und Releases hinzukommen?

Ich mach grad einen großen Sprung nach 10.3 und habe immer wieder so "Ah! Oh! das gibt´s ja schon!" Erlebnisse.

Ich kann natürlich den Code durchackern oder mir überlegen, wie die Funktion heißen könnte + suchen.

Konkret zB: Ich habe immer wieder Anweisungen der Form:

Code:

if s<>'' then
   s:=s+' ';
s:=s+'irgendwas';

Dafür hab ich mir eine Funktion gemacht. Aber sowas gibt es wahrscheinlich mittlerweile in der RTL?

Cool wäre eine Suche der Art: "strings, concatenation, separator" oder so.

In der Unit StrUtils gibts eine IfThen, in anderen units auch für andere wie Math, die sind da recht gut.

[Rudy Velthuis]

Zitat:

Zitat von Rollo62 (Beitrag 1431485)

Ein Gedanke wäre mit einem Diff-Tool die C++Header unter \Include zu vergleichen, was es dort an Änderungen/Erweiterungen so gibt.

Daran habe ich auch gedacht, aber bei einem großen Sprung kann da sehr Vieles neu sein, und dann sieht man vor lauter Bäumen den Wald nicht mehr.

Wenn ich was brauche, suche ich lieber gezielt. Meistens mit Grep über den Quelltext der mit Delphi kommt, aber auch mit Google (meist auf Englisch, z.B. "array string concatenate separator delphi ") und finde dann ziemlich schnell http://docwiki.embarcadero.com/Libra...ingHelper.Join.

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

Zitat von Uwe Raabe (Beitrag 1431489)

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:

Zitat von Schokohase (Beitrag 1431507)

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 :roll:

[mkinzler]

Zitat:

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

Das könnte leider Stimmen.

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1431632)

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

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 :stupid:

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

Zitat von Uwe Raabe (Beitrag 1431652)

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:

Zitat von Stevie (Beitrag 1431653)

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