Neue Funktionen/Methoden der RTL etc finden

[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 von 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!

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

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

[Schokohase]

Zitat von 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.

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.