Datein

[Mathias]

Zuerst dachte ich, wieso das FindAllFiles die Dateien nicht als reine String retour gibt.

Dann habe ich folgen Code geschrieben und musste feststellen, das bei Memo wie erwartet zwischen "abc" einen Zeilenumbruch kommt.
Bei ListBox wird das komischerweise nicht gemacht.

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
const
  s = 'a'#13#10'b'#13#10'c';
begin
  ListBox1.Items.Add(s);
  Memo1.Lines.Add(s);
end; 

[ruewa]

Leider hat sie [die Lazarus-Hilfe] auch ihre Grenzen, z.B. daß man die Stringliste bei FindAllFiles tunlichst nicht selbst erstellen sollte, steht dort nicht.

Wie sollte dass denn deiner Meinung nach formuliert werden? Bzw. wie käme man auf die Idee, dass man die StringListe vorher erstellen könnte?

Naja, die Hilfe zu FindAllFiles ist praktische ein leeres Blatt: http://lazarus-ccr.sourceforge.net/docs ... files.html
Sie enthält nicht einmal den Hinweis, daß die Liste innerhalb der Funktion erzeugt wird. Du hast natürlich insofern recht, als man sich das dann zusammenreimen (und notfalls im Quelltext nachsehen) kann, aber das erfordert schon einige Erfahrung. Ich sehe das auch so wie wp_xyz, daß die Liste besser als Parameter übergeben werden sollte. So ist's zwar recht elegant, aber halt auch ziemlich fehlerträchtig.

Gruß Rüdiger

[Michl]

Dann habe ich folgen Code geschrieben und musste feststellen, das bei Memo wie erwartet zwischen "abc" einen Zeilenumbruch kommt.
Bei ListBox wird das komischerweise nicht gemacht.

So sollte es gehen

Code: Alles auswählen

  ListBox1.Items.AddText(s);    

[m.fuchs]

Also ganz ehrlich: wenn ich nix reingebe, aber etwas rausbekomme, muss es drinnen erzeugt werden. Und wenn man aus dem Funktionsaufruf nicht herausliest, was man für Parameter übergibt, hat man ganz andere Probleme.

Es sollte eine Design-Regel beim Umgang mit Klassen geben, dass man Klassen nie in Funktionen und nie als var-Parameter von Prozeduren, sondern nur vor dem Aufruf mit dem eigenen Konstruktor erzeugen sollte.

Auf keinen Fall! http://de.wikipedia.org/wiki/Fabrikmethode

Wie lange sucht man an diesem Speicherleck?

Code: Alles auswählen

      Listbox.Items.Assign(FindAllFiles('c:\Lazarus'));
//oder:
Memo.Lines := FindAllFiles('c:\Lazarus');  // gefunden im englischen Lazarus-Forum

Na ich hoffe doch, dass es nur eine Heaptrace-Sitzung dauert.

Letztendlich zeigen deine Problembeispiele nur eines: derjenige der es falsch verwendet, hat das Thema OOP unter Freepascal noch nicht verstanden. Wenn diese Wissenslücke gestopft wird, hat man das Problem nicht mehr.

[wp_xyz]

okay, okay... Ich will hier keinen Glaubenskrieg entfachen, bleibe aber bei meiner Meinung und habe eben dazu einen Patch in den BugTracker hochgeladen (http://bugs.freepascal.org/view.php?id=27054).

[m.fuchs]

Wenn du meinst, dass das nötig ist. Bin gespannt ob das aufgenommen wird. Wobei mir eine Forderung aus deinem Report nicht gefällt:

[...]and mark the functions as deprecated[...]

Wenn du so eine Alternative brauchst, ist das ok. Aber deswegen jetzt die Funktionen mit deprecated zu markieren, ist über das Ziel hinausgeschossen. Es gibt ja auch Entwickler, die damit keine Probleme haben.

[ruewa]

Es gibt ja auch Entwickler, die damit keine Probleme haben.

Das ist schon richtig, Michael. Mir hat sich das, als ich zum ersten Mal auf FindAllFiles gestoßen bin, auch umstandslos aus der Deklaration erschlossen. Nur hat mich dieses Konstrukt damals nicht wenig verwundert, weil ich es als nicht konsistent mit den Programmierprinzipien von Lazarus / FreePascal empfunden habe.

Generell gilt ja: Was von Lazarus automatisch erstellt wird (z.B. GUI-Komponenten), wird auch von Lazarus wieder freigegeben. Was ich selbst erstelle, muß ich auch selbst wieder aufräumen. Ich weiß nicht, wie Du das machst, aber ich erstelle mir den Objekt-Rahmen immer in einem Stück: Sobald ich ein xyz.Create schreibe, kommen als erstes ggfls. ein paar Leerzeilen und das korrespondierende xyz.Free hinzu, sei es innerhalb einer Routine, im OnCreate / OnDestroy oder in den Initialization- / Finalization-Blöcken. Etwas freigeben zu müssen, was man nicht selbst erstellt hat, oder etwas zu erstellen, was man dann nicht freigeben muß (weil z.B. ein TStringList.OwnsObjects aktiviert ist), ist jedenfalls ein Sonderfall.

Natürlich kann man mit etwas Erfahrung mit solchen Sonderfällen klarkommen. Aber Pascal ist halt nicht nur was für ausgebuffte Entwickler, sondern eine sehr gut für die Ausbildung und den Erstkontakt mit dem Programmieren geeignete Sprache. Wer immer sich in eine Programmiersprache hineinfummelt, muß mit als erstes lernen, für welche Ordnungsmaßnahmen er verantwortlich ist, wenn er etwas in die Welt setzt. Und "Was ich erstelle, muß ich auch aufräumen" gehört dabei zum kleinen 1x1. Dieses Konsistenzprinzip in den Wind zu schlagen, nur um eine Zeile einzusparen, ist zumindest diskussionswürdig, finde ich.

Ob man das jetzt für deprecated erklären sollte (ich würde auch eher sagen, ja, aber das mag Ansichtssache sein)... Aber auf jeden Fall müßte dann in der Dokumentation dieses von den Grundschemata abweichende Konstrukt explizit thematisiert werden (wie das z.B. bei TStringList.OwnsObjects ja auch der Fall ist)! Z.B. bräuchte es den ausdrücklichen Hinweis, daß das Freigeben der Liste in der Verantwortung des Programmierers liegt und daß es einer Mittlervariable bedarf, um beispielsweise die von wp_xyz erwähnte Zuweisung an eine GUI-Komponenten-Liste vorzunehmen. Egal, ob ein erfahrener Enwickler sich das auch selber zusammenreimen kann.

Gruß Rüdiger

[m.fuchs]

Generell gilt ja: Was von Lazarus automatisch erstellt wird (z.B. GUI-Komponenten), wird auch von Lazarus wieder freigegeben.

Das ist richtig, hat aber nichts mit dem Fall zu tun. Hier wird ja nur was auf explizite Anforderung druch den Programmierer erzeugt.

Was ich selbst erstelle, muß ich auch selbst wieder aufräumen. [...] Wer immer sich in eine Programmiersprache hineinfummelt, muß mit als erstes lernen, für welche Ordnungsmaßnahmen er verantwortlich ist, wenn er etwas in die Welt setzt. Und "Was ich erstelle, muß ich auch aufräumen" gehört dabei zum kleinen 1x1. Dieses Konsistenzprinzip in den Wind zu schlagen, nur um eine Zeile einzusparen, ist zumindest diskussionswürdig, finde ich.

Ich bin voll und ganz bei dir. Das Missverständnis ist ein anderes. Du gehst davon aus, dass nur der Aufruf eines Konstruktors bedeutet, dass sich der Entwickler um das Objekt kümmern muss. Das ist aber nicht richtig. Wenn ich, auf welche Weise auch immer, ein Objekt anfordere, bin ich dafür verantwortlich. Ich muss mich um dessen Zerstörung kümmern. Das kann ich entweder selber machen (mit .Free oder besser FreeAndNil), oder ich delegiere diese Aufgabe. Indem ich das Objekt an ein anderes hänge, welches bei seinem eigenen Tod alle Kinder wegräumt.

Natürlich kann man mit etwas Erfahrung mit solchen Sonderfällen klarkommen. Aber Pascal ist halt nicht nur was für ausgebuffte Entwickler, sondern eine sehr gut für die Ausbildung und den Erstkontakt mit dem Programmieren geeignete Sprache.

Dazu muss man kein ausgebuffter Entwickler sein, aber man muss wissen wie Objektorientierung unter Freepascal funktioniert. Nicht unbedingt im Detail der VMT oder wie der Speicher belegt wird, aber zumindest den "ich hole es und mache es weg"-Teil. Für wen das zu langweilig ist, gibt es Sprachen die einen Garbage-Collector beinhalten. Mit all seinen Nachteilen.

Aber auf jeden Fall müßte dann in der Dokumentation dieses von den Grundschemata abweichende Konstrukt explizit thematisiert werden (wie das z.B. bei TStringList.OwnsObjects ja auch der Fall ist)!

Das sind unterschiedliche Sachen.

Z.B. bräuchte es den ausdrücklichen Hinweis, daß das Freigeben der Liste in der Verantwortung des Programmierers liegt und daß es einer Mittlervariable bedarf, um beispielsweise die von wp_xyz erwähnte Zuweisung an eine GUI-Komponenten-Liste vorzunehmen. Egal, ob ein erfahrener Enwickler sich das auch selber zusammenreimen kann.

Nein, es wird der Hinweis benötigt, dass der Entwickler für alle Objekte, die er erstellen lässt, verantwortlich ist. Nicht mehr, nicht weniger.

[ruewa]

Das Missverständnis ist ein anderes. Du gehst davon aus, dass nur der Aufruf eines Konstruktors bedeutet, dass sich der Entwickler um das Objekt kümmern muss. Das ist aber nicht richtig. Wenn ich, auf welche Weise auch immer, ein Objekt anfordere, bin ich dafür verantwortlich.

Michael, Du trägst gerade Eulen nach Athen. Der Punkt ist doch: Solche Fehler passieren. Klar passieren sie nur aufgrund eigener Blödheit: Wer

Code: Alles auswählen

Memo.Lines := FindAllFiles();

programmiert, der hat doch überhaupt nicht bemerkt, daß er damit eine namenlose Liste erzeugt hat. Jetzt könnte man ja sagen, soviel Dummheit kann ruhig bestraft werden, aber bei Licht betrachtet rennen wir doch alle beim Programmieren, egal auf welchem Niveau, ständig unserer eigenen Blödheit hinterher. Eine etwas andere Konstruktion würde diese Fehlermöglichkeit erst gar nicht entstehen lassen. Was ist jetzt sinnvoller? Fehlermöglichkeiten vermindern (keine Sorge, es bleiben genug übrig!), oder eine Code-Zeile einsparen (einen anderen Vorteil hat die FindAllFiles-Listen-Konstruktion m.E. nicht)? Darüber kann man trefflich streiten! Dann landet man allerdings sehr schnell bei der untergründigen Frage, ob das Programmieren einer Elite vorbehalten oder etwas für jedermann sein solle... Würde ich hochnäsig das Erstere vertreten, hätte ich für Pascal wahrscheinlich nichts als Verachtung übrig (olle Kamellen - die geistlosen Polemiken a la "Echte Kerle programmieren in ..." toben ja schon seit den 1980ern)...

Nein, es wird der Hinweis benötigt, dass der Entwickler für alle Objekte, die er erstellen lässt, verantwortlich ist. Nicht mehr, nicht weniger.

Gleiches Thema! Soll eine Dokumentation absolut minimalistisch sein oder sollte sie auch Hinweise auf Fallstricke enthalten? Tatsächlich gibt es in dieser Frage innerhalb der Lazarus-Hilfe durchaus eine gewisse Bandbreite, wie z.B. diesen Hinweis auf der FindFirst-Seite:

Attr is an or-ed combination of the following constants: (...)
It is a common misconception that Attr specifies a set of attributes which must be matched in order for a file to be included in the list. This is not so: The value of Attr specifies additional attributes, this means that the returned files are either normal files or have an attribute which is present in Attr.

Minimalistisch gesehen, hätte sowas in der Dokumentation nichts zu suchen: Wer nicht kapiert, was "or-ed" bedeutet, sei dann halt angeschmiert. Ich hingegen finde derartige Hinweise sinnvoll, und mehr noch: Schlicht die Aufgabe einer Dokumentation.

Gruß Rüdiger

P.S.: Deinen Vorschlag im Bugtracker, FindAllFiles besser in "FindAndAppendAllFiles" umzubenennen, verstehe ich ehrlich gesagt nicht. Anhängen an was? Klarer wird es dadurch m.E. nicht.

[Socke]

Attr is an or-ed combination of the following constants: (...)
It is a common misconception that Attr specifies a set of attributes which must be matched in order for a file to be included in the list. This is not so: The value of Attr specifies additional attributes, this means that the returned files are either normal files or have an attribute which is present in Attr.

Minimalistisch gesehen, hätte sowas in der Dokumentation nichts zu suchen: Wer nicht kapiert, was "or-ed" bedeutet, sei dann halt angeschmiert. Ich hingegen finde derartige Hinweise sinnvoll, und mehr noch: Schlicht die Aufgabe einer Dokumentation.

Das Beispiel ist nicht ganz treffend: das or bezieht sich auf den bitweisen Operator or, mit dem Die Attribute verknüpft werden. Das sagt nichts über die Verwendung innerhalb der Funktion aus. Daher muss das in der Dokumentation geklärt werden.

Das Missverständnis ist ein anderes. Du gehst davon aus, dass nur der Aufruf eines Konstruktors bedeutet, dass sich der Entwickler um das Objekt kümmern muss. Das ist aber nicht richtig. Wenn ich, auf welche Weise auch immer, ein Objekt anfordere, bin ich dafür verantwortlich.

Michael, Du trägst gerade Eulen nach Athen. Der Punkt ist doch: Solche Fehler passieren. Klar passieren sie nur aufgrund eigener Blödheit: Wer

Code: Alles auswählen

Memo.Lines := FindAllFiles();

programmiert, der hat doch überhaupt nicht bemerkt, daß er damit eine namenlose Liste erzeugt hat. Jetzt könnte man ja sagen, soviel Dummheit kann ruhig bestraft werden, aber bei Licht betrachtet rennen wir doch alle beim Programmieren, egal auf welchem Niveau, ständig unserer eigenen Blödheit hinterher. Eine etwas andere Konstruktion würde diese Fehlermöglichkeit erst gar nicht entstehen lassen. Was ist jetzt sinnvoller? Fehlermöglichkeiten vermindern (keine Sorge, es bleiben genug übrig!), oder eine Code-Zeile einsparen (einen anderen Vorteil hat die FindAllFiles-Listen-Konstruktion m.E. nicht)? Darüber kann man trefflich streiten! Dann landet man allerdings sehr schnell bei der untergründigen Frage, ob das Programmieren einer Elite vorbehalten oder etwas für jedermann sein solle... Würde ich hochnäsig das Erstere vertreten, hätte ich für Pascal wahrscheinlich nichts als Verachtung übrig (olle Kamellen - die geistlosen Polemiken a la "Echte Kerle programmieren in ..." toben ja schon seit den 1980ern)...

Auch ich habe das subjektive Gefühl, dass diese Funktion ein wenig von den sonst anzutreffenden Gepflogenheiten abweicht. Das heißt nicht, dass es falsch ist. Es heißt schlicht: das Fabrikmuster ist in Pascal gefühlt wenig verbreitet. Wir sollten uns darauf konzentrieren, den Leuten beizubringen, wie sie das alles verstehen und korrekt anwenden können.

Was die technische Sache angeht, sehe ich das recht einfach: Wenn ein Objekt zurück kommt, muss man sich um dessen Freigabe kümmern; wenn man eins hinein gibt muss es schon vorhanden sein.

[m.fuchs]

Michael, Du trägst gerade Eulen nach Athen. Der Punkt ist doch: Solche Fehler passieren. Klar passieren sie nur aufgrund eigener Blödheit: Wer

Code: Alles auswählen

Memo.Lines := FindAllFiles();

programmiert, der hat doch überhaupt nicht bemerkt, daß er damit eine namenlose Liste erzeugt hat. Jetzt könnte man ja sagen, soviel Dummheit kann ruhig bestraft werden, aber bei Licht betrachtet rennen wir doch alle beim Programmieren, egal auf welchem Niveau, ständig unserer eigenen Blödheit hinterher. Eine etwas andere Konstruktion würde diese Fehlermöglichkeit erst gar nicht entstehen lassen. Was ist jetzt sinnvoller? Fehlermöglichkeiten vermindern (keine Sorge, es bleiben genug übrig!),

Toll, und dann steht er beim nächsten Mal vor dem gleichen Problem. Weil das Factory-Pattern durchaus benutzt wird. Ich habe ein ORM-Framework, das gibt bei jeder Datenbankabfrage neue Objekte zurück. Und dafür gibt es sicher noch weitere Beispiele. Diese einen Stein aus dem Weg zu räumen, anstatt den Hintergrund zu erklären, hilft auf Dauer keinem Entwickler. Und nochmal: der Hintergrund ist essentiell "Räum hinter dir auf!". Das ist nichts, was man in ObjectPascal umgehen kann.

oder eine Code-Zeile einsparen (einen anderen Vorteil hat die FindAllFiles-Listen-Konstruktion m.E. nicht)?[/code]

Es geht hier nicht um das Einsparen von Codezeilen. Davon bin ich sowieso kein Freund. Wer wenig tippen will, soll C nehmen. Pascal schreibt man ja so ausführlich, damit es verständlicher ist.
Die neue Prozedur ist übrigens nicht weniger verwirrend. AList? Was soll das sein? Zusätzliche Parameter? Eine Liste von Dateinamen? Ach, das Ergebnis.

Darüber kann man trefflich streiten! Dann landet man allerdings sehr schnell bei der untergründigen Frage, ob das Programmieren einer Elite vorbehalten oder etwas für jedermann sein solle... Würde ich hochnäsig das Erstere vertreten, hätte ich für Pascal wahrscheinlich nichts als Verachtung übrig (olle Kamellen - die geistlosen Polemiken a la "Echte Kerle programmieren in ..." toben ja schon seit den 1980ern)...

Nein, es geht darum, dass die echten Kerle den Neulingen erklären, wie es geht. Und nicht darum, es für sie so leicht zu machen, dass sie niemals ein echter Kerl werden können.

P.S.: Deinen Vorschlag im Bugtracker, FindAllFiles besser in "FindAndAppendAllFiles" umzubenennen, verstehe ich ehrlich gesagt nicht. Anhängen an was? Klarer wird es dadurch m.E. nicht.

Ja, man könnte noch AppendToList daraus machen. Regel aus dem Clean-Code-Design: Methodennamen sollen ausdrücken, was sie machen. In dem neuen Entwurf sollte also ncoh klar werden, dass das Ergebnis an die übergebene Liste angehagen wird. Das ist natürlich bei der Funktion nicht nötig.

[ruewa]

Whow! Der Eifer, mit dem das nun plötzlich zur Grundsatzfrage angewachsen ist (die zudem auf der Bugtrackerseite fortgeführt wird), verblüfft mich jetzt schon.

Toll, und dann steht er beim nächsten Mal vor dem gleichen Problem. Weil das Factory-Pattern durchaus benutzt wird. Ich habe ein ORM-Framework, das gibt bei jeder Datenbankabfrage neue Objekte zurück. Und dafür gibt es sicher noch weitere Beispiele. Diese einen Stein aus dem Weg zu räumen, anstatt den Hintergrund zu erklären, hilft auf Dauer keinem Entwickler.

Wie willst Du "den Hintergrund erklären", wenn Du gleichzeitig vehement argumentierst, in der Dokumentation hätte ein Hinweis darauf aber nichts zu suchen?

Die neue Prozedur ist übrigens nicht weniger verwirrend. AList? Was soll das sein? Zusätzliche Parameter? Eine Liste von Dateinamen? Ach, das Ergebnis.

Das meinst Du jetzt nicht wirklich ernst, oder? Was ist an an einer Deklaration "procedure xyz(AList: TStrings, ...)" "nicht weniger verwirrend"?

Wir sollten uns darauf konzentrieren, den Leuten beizubringen, wie sie das alles verstehen und korrekt anwenden können.

Nein, es geht darum, dass die echten Kerle den Neulingen erklären, wie es geht. Und nicht darum, es für sie so leicht zu machen, dass sie niemals ein echter Kerl werden können.

Na dann mal frisch ans Werk, Jungs! Bloß wie soll das gehen, wenn entsprechende Erläuterungen partout nicht in die Dokumentation einfließen dürfen? Oder sollte "Forumsguru klärt Frischling auf" das tragende Vermittlungsmuster sein? Das riecht mir jedenfalls ein wenig zu penetrant nach Verkehrserzieher-Attitude...

Tut mir leid, ich sehe das viel pragmatischer: Wir hangeln uns doch ständig von einem Verständnisproblem zum nächsten. Wenn man eines davon mal für alle Nachfolgenden entschärfen kann, was ist dann das Problem dabei? Ich neige persönlich eher zu wp_xyz's Variante, kann aber auch gut mit der Funktion FindAllFiles leben, wie sie derzeit ist. Dann aber sollte die Problematik auch in die Dokumentation einfließen, anstatt jedermann absichtsvoll auflaufen zu lassen, der nicht Eurer Vorstellung des einzig wahren Lernpfades folgt. Was soll denn das? Zumal Ihr kein Konzept erkennen laßt, wie Ihr den "Neulingen" "beibringen" wollt, zu "echten Kerlen" zu werden.

Aber ich sehe schon, Michael, Du hast zu dem Wort von den "echten Kerlen" offenbar auch einen entschieden weniger kabarettistischen Bezug als ich...

Gruß Rüdiger

[m.fuchs]

Aber ich sehe schon, Michael, Du hast zu dem Wort von den "echten Kerlen" offenbar auch einen entschieden weniger kabarettistischen Bezug als ich...

Herrje, du hast es eingebracht, also habe ich in der Antwort auf Smilies oder Anführungszeichen verzichtet. Kommt hier gerne nochmal hinterher: "echte Kerle"

Whow! Der Eifer, mit dem das nun plötzlich zur Grundsatzfrage angewachsen ist (die zudem auf der Bugtrackerseite fortgeführt wird), verblüfft mich jetzt schon.

Aber das ist doch gut, ohne engagierte Diskussion ist das Leben ja langweilig und der Weiterentwicklung kommt auch nicht so recht voran. Wir wollen doch hier keine Politbüro-Atmosphäre. Umgekehrt gehe ich natürlich auch davon aus, dass die Diskussion von keinem persönlich genommen wird.

Wie willst Du "den Hintergrund erklären", wenn Du gleichzeitig vehement argumentierst, in der Dokumentation hätte ein Hinweis darauf aber nichts zu suchen?

Das hätte ich vielelicht klarer ausdrücken sollen, in der Dokumentation zu dieser speziellen Funktion ist eine Warnung übertrieben. Das gehört in das Tutorial für objektorientiertes Programmieren. Andernfalls müsste man ja bei jeder Funktion die ein Objekt zurückgibt, diese Warnung einfügen. Das wäre doch nicht zielführend. Grundlagen gehören in den Grundlagenteil. Im Dokumentationsteil für die Bibliotheken gehören die relevanten Informationen zu dem entsprechenden Code.

Die neue Prozedur ist übrigens nicht weniger verwirrend. AList? Was soll das sein? Zusätzliche Parameter? Eine Liste von Dateinamen? Ach, das Ergebnis.

Das meinst Du jetzt nicht wirklich ernst, oder?

Doch das meine ich ernst.

Was ist an an einer Deklaration "procedure xyz(AList: TStrings, ...)" "nicht weniger verwirrend"?

Komtm drauf an, wie genau xyz jetzt heißt. Beim Namen procedure UpcaseStrings(AList: TStrings, ...) bleiben sicherlich keine Fragen offen. FindFiles aber, sagt nichts darüber aus, dass ich eine Liste für das Ergebnis reingeben muss. Da sollte der Parameter schon ResultList oder so heißen.

[Michl]

Komtm drauf an, wie genau xyz jetzt heißt.

Hier im Forum? Na wp natürlich

[ruewa]

Aber das ist doch gut, ohne engagierte Diskussion ist das Leben ja langweilig und der Weiterentwicklung kommt auch nicht so recht voran. Wir wollen doch hier keine Politbüro-Atmosphäre. Umgekehrt gehe ich natürlich auch davon aus, dass die Diskussion von keinem persönlich genommen wird.

Da hast Du allerdings auch wieder recht!

... in der Dokumentation zu dieser speziellen Funktion ist eine Warnung übertrieben. Das gehört in das Tutorial für objektorientiertes Programmieren. Andernfalls müsste man ja bei jeder Funktion die ein Objekt zurückgibt, diese Warnung einfügen...

Ja und? Soviele sind das ja nicht. Warum kann man das nicht sowohl in ein Tutorial als auch in die Funktions-Beschreibung packen? Was ist so tragisch an ein bißchen Redundanz?

Das wäre doch nicht zielführend. Grundlagen gehören in den Grundlagenteil. Im Dokumentationsteil für die Bibliotheken gehören die relevanten Informationen zu dem entsprechenden Code.

Entschuldige, aber das ist mir zu schematisch gedacht, allzu deutsch, prinzipienverhaftet. Informationen sollten vernünftigerweise dort liegen, wo man sie ohnehin sucht. Wer die Besonderheit der FindAllFiles-Deklaration nicht umstandslos durchdringt, der wird auch kaum auf Anhieb zu dem Ergebnis kommen, daß er gefälligst erst einmal den "Grundlagenteil" aufzusuchen hat. So funktioniert menschliches Lernen einfach nicht. Und sind das denn keine "relevanten Informationen zu dem entsprechenden Code"?

Aber was soll das ewige theoretisch-drüber-reden: Machen wir doch einfach mal Butter bei die Fische: Was spricht ernsthaft dagegen, in die Dokumentation von FindAllFiles und FindAllDirectories die folgenden zwei Absätze einzupflegen?

Code: Alles auswählen

Please note: FindAllFiles creates the resulting Stringlist and the programmer is responsible for freeing this Stringlist afterwards. Therefore you should always use an intermediate variable for taking the function result. To avoid memory leaks you should never assign the function result directly to a TStrings-property (e.g. Memo.Lines := FindAllFiles()): This would copy the Stringlists content (according to the properties write-method) while leaving the source list without a reference.
 
Example:
var
  SL : TStringList;
begin
  try
    SL := FindAllFiles('.');
    Memo.Lines := SL;
  finally
    SL.Free;
  end;
end;
 

Mal abgesehen von meinem schauderhaften Englisch: Was spricht dagegen? (Klar müßte man an der Formulierung noch arbeiten, Verbesserungsvorschläge sind willkommen!)

Ansonsten: Aus der Namensdiskussion halte ich mich raus, da gäbe es viel zu bemängeln. Ich hatte mich erst kürzlich damit rumgeschlagen, als ich ShortString-Alternativen zu CompareStr und CompareText geschrieben habe: Der Unterschied zwischen diesen beiden Funktionen ist, daß die eine einen Case-sensitiven Vergleich anstellt, die andere einen insensitiven. Selbst wenn man das weiß, rätselt man, welcher Name denn nun zu welcher Funktionalität gehören könnte... Insofern stimme ich Dir einerseits ausdrücklich zu, man sollte an der Namensgebung wirklich ausgiebig feilen. Aber bei dem, was schon da ist, ist das ein Faß ohne Boden (wobei ich mich zudem frage, wie Du einen Namenswechsel vollziehen willst, ohne ebenfalls den alten Namen für deprecated zu erklären?).

Ernsthaft: Würde sich das Problem nicht weitgehend zu (fast) jedermanns Zufriedenheit in Luft auflösen, wenn man die Dokumentation einfach um einen solchen Part ergänzen würde?

Gruß Rüdiger