For xx In xxx Schleife rückwärts?

[Panthrax]

Einträge in einer Reihenfolge anzuordnen gehört sowohl zum Wesen einer Liste als auch zum Wesen einer Aufzählung. Es ist wenigstens intuitiv, zu erwarten, dass die Aufzählung einer Liste die Einträge in eben dieser Reihenfolge liefert - und dass diese Reihenfolge umgekehrt werden kann.

Sich dieser Intuition zu verweigern ist ein Fehler. Man kann Menschen auch unnötig verunsichern, wenn man gegen ihren gesunden Verstand redet.

Es ist nicht die For-in-Anweisung, welche die Reihenfolge bestimmt, sondern der Aufzähler. Auch die Übersetzung der Schleife für parallele Ausführung wird diese Reihenfolge nicht ändern. Wenn festgestellt werden kann, dass derselbe Schleifenkörper mehrmals parallel ausgeführt werden kann, bedeutet das nur, dass die Bearbeitung unabhängig von der Aufzählungsreihenfolge ist.

---------------

Zitat von milos:

Ist es möglich in eine For-in-Schleife rückwärts laufen zu lassen, ohne dass man in der Liste etwas dreht?

[Furtbichler]

Zitat von Panthrax:

Einträge in einer Reihenfolge anzuordnen gehört sowohl zum Wesen einer Liste als auch zum Wesen einer Aufzählung.

Nö. Nimm Dir ein RDBMS und verwende einen serverseitigen Cursor ohne explizite Ordnung (d.h. ein 'SELECT' ohne 'ORDER BY'): Auf diese Reihenfolge kannst Du dich nicht verlassen.

Anderes Beispiel:

Delphi-Quellcode:

MyList.Add(1);
MyList.Add(3);
MyList.Add(2);
For element in MyList do
  Writeln(element);

Preisfrage: In welcher Reihenfolge werden die Elemente ausgegeben?

[Panthrax]

Zitat von Furtbichler:

Nö. Nimm Dir ein RDBMS und verwende einen serverseitigen Cursor ohne explizite Ordnung (d.h. ein 'SELECT' ohne 'ORDER BY'): Auf diese Reihenfolge kannst Du dich nicht verlassen.

Was ist in diesem Beispiel die Liste? Das Ergebnis einer Select-Abfrage ist sehr wohl eine Liste, und wiederholtes Aufzählen ihrer Einträge ergäbe eine immer gleiche Reihenfolge. Eine neue Select-Abfrage erstellt eine neue Liste. Ein Cursor ist weder eine Liste, noch bedeutet "Cursor", dass er in einer navigiert.

Zitat von Furtbichler:

Delphi-Quellcode:

MyList.Add(1);
MyList.Add(3);
MyList.Add(2);
For element in MyList do
  Writeln(element);

Preisfrage: In welcher Reihenfolge werden die Elemente ausgegeben?

Code:

1
3
2

Eine andere Reihenfolge ist ein Fehler.

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

[Furtbichler]

Du bist ja ein richtiger Fachmann.

Zitat von Panthrax:

Was ist in diesem Beispiel die Liste?

Die Tabelle.
Ein Enumerator hat genauso viel mit einer Liste zu tun wie ein Cursor mit einer Tabelle.
Der Cursor zählt die Query auf, der Enumerator die Liste. Wo und wie ist denn die Reihenfolge definiert, wenn die nicht explizit festgelegt ist? Heute kommen die Daten so, morgen so. Glaubste nicht? Tja, dann fehlt dir was.

Zitat:

Eine andere Reihenfolge ist ein Fehler.

Ach, echt? Hatte ich erwähnt, das es sich um eine TSortedList handelt (1,2,3). oder eine TLinguisticSortedList? (3,1,2). Oder eine Hashmap? Oder. Oder. Oder.
Also nochmal, für Hausfrauen, zum Mitschreiben: Die Reihenfolge der Aufzählung ist implementierungsabhängig, mithin undefiniert (obwohl meistens deterministisch) und im Einzelfall durchaus heute anders als morgen. Sie darf auch nichtdeterministisch sein (RDBMS), d.h. jedesmal in einer anderen Reihenfolge. Der einzige Grund, weshalb das i.a. nicht der Fall ist, ist doch der, das es naheliegend ist, das ein Array oder eine Liste die Elemente mit einem Index aufzählt. Aber wie sieht es mit der Reihenfilge bei einer Hashmap aus? Oder einem Baum? Wie ist denn die Reihenfolge hier? Infix, Prefix, Postfix? Was ist mit einem ungerichteten Graphen? Trie? etc. etc. etc.

Deshalb hat man doch gerade das gemeinsame IEnumerable-Paradigma, um die einzelnen Elemente wenigstens aufzählen zu können, auch Mengen ohne innere Ordnung. Mann, so schwer kann das doch nicht sein.

[Panthrax]

Zitat von Furtbichler:

Zitat:

Eine andere Reihenfolge ist ein Fehler.

Ach, echt? Hatte ich erwähnt, das es sich um eine TSortedList handelt (1,2,3). Oder eine TLinguisticSortedList? (3,1,2). Oder eine Hashmap? Oder. Oder. Oder.

Nein, hatten Sie nicht. Was nicht dasteht kann nicht bewertet werden. Im übrigen widersprechen Sie auf ihren Umwegen ja auch nicht. Meine vorigen Beiträge sind auch ausreichend Antwort bis hierhin. Vielleicht finden Sie ja wirklich bestätigend viele Leute in Ihrem Umfeld, die Sie bitten können einmal aufzuzählen was auf Ihrer Einkaufsliste steht, und die dann wirklich jedes Mal die Liste anders rauf- und runterspringen. Ich würde ja meinen sie würden es einfach von vorn nach hinten durchlesen. In der Tat, so schwer kann das doch nicht sein.

Nun denn, wenn es darum geht Liste zu nennen, was keine ist, und Dinge nicht so zu implementieren, wie es ihr Name sagt, und man dabei Unsicherheit wider der Vernunft streut, während man beim Programmieren selbst immer wieder in die Defensive gerät - denn es könnte sich ja immer alles auch ein bisschen anders verhalten - dann sind wir beim Etikettenschwindel angekommen:

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

Stichwort: Produktivität. - Ich bin raus.