For xx In xxx Schleife rückwärts?

[jaenicke]

Zitat von Panthrax:

Eine andere Reihenfolge ist ein Fehler.

Delphi-Quellcode:

var
  Test: TDictionary<Integer, String>;
  Current: TPair<Integer, String>;
begin
  Test := TDictionary<Integer, String>.Create;
  try
    Test.Add(1, 'Eins');
    Test.Add(2, 'Zwei');
    Test.Add(3, 'Drei');
    for Current in Test do
      ShowMessage(Current.Value);
  finally
    Test.Free;
  end;
end;

Das heißt es ist auch ein Fehler, dass dort nicht Eins, Zwei, Drei herauskommt?

for..in heißt nur "gehe alle Elemente durch". Nicht mehr und nicht weniger.

[Panthrax]

Zitat von jaenicke:

Das heißt es ist auch ein Fehler, dass dort nicht Eins, Zwei, Drei herauskommt?

Nein, kein Fehler, es ist keine Liste.

Die For-in-Schleife geht alle Elemente einer Aufzählung durch. Und das Aufzählen einer Liste geschieht von vorn nach hinten.

[jaenicke]

Eben. In der Benutzung ist es aber exakt gleich. Heißt: Man müsste bei der Betrachtung stets nachschauen von was denn die Klasse, die in einem Quelltext benutzt wird, abgeleitet ist, um beurteilen zu können, ob ein Quelltext macht was er soll.

Und das ist ein No-Go in sauberem Quelltext.

[himitsu]

Aber wie am Beispiel des TList.Reversed, kann man die Funktion auch direkt am Quellcode dokumentieren.

Also wenn man eine bestimmre Reihenfolge benötigt, dann kann man auch einen passenden Enumerator auch direkt angeben.
Wie z.B. einen rückwärttslaufenden Enumerator, oder Einen, welcher die Liste vorher cached, wenn man innerhalb der Schleife die Liste verändern möchte,
oder einen Enumerator, welcher die Liste gefilltert durchläuft und nur bestimmte Einträge behandelt.

[Panthrax]

Zitat von jaenicke:

In der Benutzung ist es aber exakt gleich. Heißt: Man müsste bei der Betrachtung stets nachschauen von was denn die Klasse, die in einem Quelltext benutzt wird, abgeleitet ist, um beurteilen zu können, ob ein Quelltext macht was er soll.

Richtig! Vielleicht noch einmal zur Erinnerung (und unter Berücksichtigung der Bindung durch den Compiler), der Aufruf einer Methode wird konzeptionell zurückgeführt auf den Aufruf einer Routine mit dem Objekt als erstem Parameter:

Delphi-Quellcode:

Objekt.Methode(Argument);
Methode(Objekt, Argument);

Kein Parameter ohne Bedeutung: Das Objekt stellt einen Zusammenhang mit Daten her und die Klasse des Objekts stellt einen Zusammenhang mit Funktionen her. Stichwort: Polymorphie.

Anderes Beispiel:

Delphi-Quellcode:

program Project1;

{$AppType Console}

uses
  System.SysUtils,
  Spring.Collections,
  Spring.Collections.Lists,
  Spring.Collections.Sets;

type
  T = String;

procedure Enumerate(const Caption: String; const Enumerable: IEnumerable<T>);
var
  Value: T;
begin
  WriteLn(Caption);
  for Value in Enumerable do
    WriteLn(Value);
end;

procedure Run;
var
  Collection1: IList<T>;
  Collection2: ISet<T>;
  Value: T;
begin
  Collection1 := TList<T>.Create;
  Collection2 := THashSet<T>.Create;

  Collection1.Add('Eins.');
  Collection1.Add('Eins.');
  Collection1.Add('Zwei.');
  Collection1.Add('Drei.');
  Collection1.Add('Vier.');
  Collection1.Add('Drei.');

  for Value in Collection1 do
    Collection2.Add(Value);

  Enumerate('Aufzählung 1', Collection1);
  Enumerate('Aufzählung 2', Collection2);
end;

begin
  try
    Run;
  except
    on E: Exception do
      WriteLn(E.ClassName + ': ' + E.Message);
  end;

  if DebugHook <> 0 then
    ReadLn;
end.

Ausgabe:

Code:

Aufzählung 1
Eins.
Eins.
Zwei.
Drei.
Vier.
Drei.
Aufzählung 2
Zwei.
Drei.
Eins.
Vier.

Das verdeutlicht vielleicht noch einmal auf andere Weise, dass das Objekt und seine Klasse bedeutsam sind für das, welche Funktion mit welchen Daten ausgeführt werden soll. Dieses Verhalten ist erwünscht und der wesentliche Grund dafür, warum wir Polymorphie nutzen. Bspw. Add ist für eine Liste eben anders definiert als für eine Menge. Gleichermaßen ist eine Aufzählung für eine Liste klar definiert, und kann durchaus von anderen Aufzählungen anderer Typen abweichen. Gleichsam sind beides Sammlungen und beide aufzählbar, was bei der Routine Enumerate nützlich ist. Und eine Menge bietet eben keinen indizierten Zugriff auf ihre Elemente, der für eine For-to-Schleife benötigt wird. Er müsste erst künstlich geschaffen werden. Genauso bei dem TDictionary<...> -Beispiel von oben; IDictionary<NativeInt, String> und IList<TPair<NativeInt, String>> sind eben unterschiedliche Typen, auch wenn beide einen IEnumerator<TPair<NativeInt, String>> anbieten.

[Medium]

Code, bei dem ich erst die Klassenhierarchie studieren müsste um herauszufinden wie meine Schleife läuft (und dies relevant ist), würde ich dem Autor sowas von um die Ohren knallen, das glaubst du gar nicht. Das ist bewusstes torpedieren von Teamarbeit und Produktivität.