TStringList als Result einer Funktion

[DeddyH]

Das find ich aber sehr verwirrend, denn ob man nun schreibt
sl := CreateList(TStringList.Create); oder
sl := CreateList(nil); , tut sich im Endergebnis nichts.

[bernau]

Zitat von mkinzler:

Kompromiss:

Grauselig. Man muss m.E. nach sofort erkennen, daß ein Objekt erzeugt wird. Dazu gekört für mich der Klassenname in Verbindung mit dem Create. Danach mit einer Funktion füllen (Wie der Vorschlag von Dejan Vu)

Delphi-Quellcode:

sl:=TStringlist.create;
FillTiere(sl);

Oder man erkennt aus dem Funktionsnamen direkt, daß eine Klasse erzeugt wird.

Delphi-Quellcode:

function StringlistCreateWithTiere: TStringList;
begin
   Result:=TStringList.create;
   Result.Add('Hund');
   Result.Add('Katze');
   Result.Add('Maus');
end;

[mkinzler]

Zitat von Dejan Vu:

Na ja. Formal korrekt. Würdest Du das so schreiben und verwenden?

Nein, aus, unter anderem, den genannten Gründen.

[DeddyH]

Ich bin auch überhaupt kein Freund von Funktionen, die Objektinstanzen zurückgeben, welche innerhalb der Funktion angelegt werden. Ich finde ihn gerade nicht, aber wir hatten hier mal einen Thread, wo ungefähr Folgendes gemacht wurde:

Delphi-Quellcode:

function ReturnsStrings: TStrings;
begin
  Result := TStringlist.Create;
  ...
end;

for i := 0 to ReturnsStrings.Count - 1 do
  Bearbeite(ReturnsStrings[i]);

Klar, mit einer einfachen Zwischenvariablen wäre das Problem vom Tisch, aber hätte man gleich eine Prozedur mit einem TStrings-Parameter daraus gemacht, wäre der obige Code so gar nicht möglich gewesen.

[himitsu]

Wenn ReturnsStrings zu diesem Zeitpunkt immer das Selbe zurück gibt, dann würde der Code zumindestens funktionieren. (bis auf ein paar Speicherlecks und eventuell einer langsameren Verarbeitung, jenachdem wie schnell das ReturnsStrings war)

Unter iOS/Android gibt es diese Speicherlecks nicht.

[sx2008]

Ich würde ganz klar den Vorschlag von DeddyH (Beitrag #16) bevorzugen wenn auch mit kleinen Änderungen.
Das Clear wird weggelassen und der Name beginnt mit Appendxxx.

Delphi-Quellcode:

procedure AppendTiere(const Dest: TStrings);
begin
  Assert(Assigned(Dest));
  Dest.BeginUpdate;
  try
    Dest.Add('Hund');
    Dest.Add('Katze');
    Dest.Add('Maus');
  finally
    Dest.EndUpdate;
  end;
end;

Je nach Anwendungsfall kann man das Clear auch dazunehmen; nur dann beginnt die Prozedure mit Fillxxx.
Wenn ich weiss, dass die Prozedure nicht mehr als 100 Einträge erzeugen wird, dann lasse ich auch BeginUpdate und EndUpdate weg.

[Sir Rufo]

Nur so aus Spass (dann sind doch alle glücklich)

Delphi-Quellcode:

procedure FillWithAnimals( const Dest: TStrings; Append : Boolean = False );
begin
  Assert(Assigned(Dest));
  Dest.BeginUpdate;
  try
    if not Append then
      Dest.Clear;
    Dest.Add('Hund');
    Dest.Add('Katze');
    Dest.Add('Maus');
  finally
    Dest.EndUpdate;
  end;
end;

[himitsu]

Zitat von Sir Rufo:

Nur so aus Spass (dann sind doch alle glücklich)

Ähhhhhhhhhhhhhhhhhhhhhhhhhhh....

Ne


Append wird ja immer gemacht, aber das Clear wird gesteuert.

Delphi-Quellcode:

procedure FillWithAnimals(Dest: TStrings; Clear: Boolean=False); 
// oder doch AppendAnimals (ohne Denglisch), ist nun auch egal, wobei es ja dennoch immer Append macht

Ja, Const ist schon richtig, da die Referenz wirklich nicht verändert wird, aber da man was in der Klasse verändert (hinzufügt), finde ich es imho etwas "verwirrend".
Wobei var natückich "logisch" gesehn eindeutiger wäre, aber in Bezug auf den Zeiger ja vollkommen falsch ... dann doch lieber ohne.

Mir würde es ja gefallen, wenn man für Klassen/Zeigertypen dennoch ein IN und OUT angeben könnte, als Info für den Entwickler. (wobei man das ja im HelpInsigt/DokuInsigt machen könnte, wenn man es da einführen täte)

Und hier ist das Problem mit der typisierung besonders groß.
> mit VAR könnte man nur genau diesen Typen, als übergebene Variable verwenden und was drin ist, ist egal
> bei TStringList kann man nur TStringList und Nachfahren reingeben, obwohl intern nur Methoden des TStrings verwendet werden
> mit TStrings wäre auch ein Memo.Lines möglich

[Sir Rufo]

Eventuell ist mein englisch eingerostet, aber bei Fill erwarte ich, dass die Liste gefüllt und eben nicht aufgefüllt wird (wäre dann ja Fillup). Darum der Parameter Append mit default False .

Es kommt also nicht darauf an, was gemacht wird, sondern was der Name nahelegt und logisch ist.

Deine Funktion müsste also logischerweise procedure AppendAnimals( Dest: TStrings; Clear: Boolean=False ); heissen.

[DeddyH]

Man kann auch einen eigenen Aufzählungstyp samt Parameter dieses Typs definieren, der besagt, ob vorne oder hinten angehängt oder die Liste vorher gelöscht werden soll. Damit sollten dann wirklich alle zufrieden sein.