Linq To Object - Gibts sowas wie eine set Methode

Ich nutze und liebe sehr stark Linq To Object. Was ich vermisse ist sowas wie eine "Set" Routine, wo ich Werte für die gesamte Liste setzen kann. Habe ich da was übersehen? Klar kann ich das mit einer Foreach - Schleife machen, aber

List<Object>.Set (o => o.Id = 1) wäre doch besser oder?

oder geht das irgendwie?

hm es gibt doch auch eine extra ForEach Methode dafür:

Beispiel:

        public class Foo
        {
            #region Public Properties
            public string Bar { get; set; }
            #endregion

            #region Constructors
            public Foo()
            {

            }
            #endregion
        }

        static void Main(string[] args)
        {
            List<Foo> foos = new List<Foo>();
            foos.Add(new Foo());
            foos.Add(new Foo());
            foos.Add(new Foo());
            foos.Add(new Foo());

            foos.ForEach(x => x.Bar = "FooBar");
        }

Also bei mir kennt er die ForEach auch nicht!? Hast du es jetzt hinbekommen?

Habs gefunden!

Habe folgendes in Winforms gemacht:

Controls.OfType<Button>().ForEach... // geht nicht!
Controls.OfType<Button>().ToList().ForEach... // geht!!!

Also bei mir kennt er die ForEach auch nicht!? Hast du es jetzt hinbekommen?

Ich hatte anfangs IList<Foo> foos = new List<Foo>(); geschrieben und hab mich auch erstmal gewundert warum es kein ForEach gibt, hab den Fehler dann aber gefunden 🙂

Hallo zusammen

<Object>.ToList().ForEach(.... halte ich nicht für sinnvoll.
Am besten für IEnumerable<T> eine eigene Extensionmethod schreiben, bspw.:

public static void ForEach<T>(this IEnumerable<T> source, Action<T> action)
{
    foreach(var item in source)
    {
        action(item);
    }
}

Gruss Peter

<Object>.ToList().ForEach(.... halte ich nicht für sinnvoll.

Warum nicht? Ist doch auch nichts anderes?!

Salute Bubblegum

Doch, für mich ein Missbrauch der List<T>-Klasse.
Du machst eine List, nur um eine Methode zu haben, die du auch mit einem normalen IEnumerable<T> nachbilden kannst.

Es verschlechtert die Lesbarkeit und du erkaufst dir mit diesem überflüssigen Aufruf eine Abhängigkeit auf List<T>.

Ausserdem um einiges performanter und flexibler.

Gruss Peter

@ Peter Bucher: FULLACK

Ja, das mit der Performance bzgl. ToList() ist ja klar, aber die Funktionsweise ist bei beiden Varianten gleich. Warum MS ForEach aber nur für List<T> und nicht IEnumerable<T> spendiert hat, bleibt mir aber ein Rätsel?!

Salute Bubblegum

Ich habe meinen Beitrag noch ergänzt.
Es gibt also noch einiges mehr als nur der Performancenachteil.

Wieso MS das nicht eingebaut hat, ist mir auch ein Rätsel,
aber wild ist es ja nicht, vorallem weil du ja den Code schon hast 😉

Gruss Peter

Ja, das mit der Performance bzgl. ToList() ist ja klar, aber die Funktionsweise ist bei beiden Varianten gleich. Warum MS ForEach aber nur für List<T> und nicht IEnumerable<T> spendiert hat, bleibt mir aber ein Rätsel?!

Weil die Funktionsweisen eben nicht gleich sind. List<T>.ForEach() arbeitet intern nicht mit einem Enumerator (kein Nutzen von MoveNext()/GetEnumerator()) sondern mit einem for-loop über die Size der Liste - was bei einem IEnumerable absolut keinen Sinn macht.

Performance-technisch ist die "optimierte forEach (bzw. der for-loop)" also etwas Fixer als die Enumerator foreach Version.

Hallo,

so eine Set Methode würde im Prinzip das q aus dem Namen Linq missachten. Es heißt query - Abfrage, und alle Linq Operatoren ändern niemals die Ursprungsaufzählung. Genau das willst du ja aber. Deshalb wird so eine Funktion niemals ins IEnumerable<T> Interface wandern, weils semantisch nicht zu Linq passt.

Hallo,
Deshalb wird so eine Funktion niemals ins IEnumerable<T> Interface wandern, weils semantisch nicht zu Linq passt.

Naja, IEnumerable ist vielleicht das Herz-Stück Linqs, aber dennoch nicht exklusiv an Linq gebunden.

IEnumerable implementiert eine Iterationsmöglichkeit über Elemente. Nicht mehr, nicht weniger. Einen Action-Delegaten einzufügen mag Sinn machen oder auch nicht.
Dennoch man kann relativ leicht nachvollziehen, dass das Interface IEnumerable einen anderen Scope bekommen, falls es mehr als ein Iterieren (nämlich besagten Action-Delegat, wie in List<T>.ForEach()) implementieren würde. Das ist vermutlich der Grund, warum es nicht implemtiert ist und auch nie werden wird. Das Verhalten ist dann einfach nicht mehr das, was ich mit IEnumerable ausdrücken will. Und daher würde ich sagen:

Deshalb wird so eine Funktion niemals ins IEnumerable<T> Interface wandern, weils semantisch nicht zu "IEnumerable<T>" passt

Okay, war vielleicht nicht ganz richtig ausgedrückt.

IEnumerable<T> als Interface definiert ja eh nur die Funktion GetEnumerator und daran kann sich auch nichts mehr ändern. Wenns um Linq geht, gehts natürlich um die ganzen Extension Methods für IEnumerable<T> und von daher stimmt meine Aussage schon, wenn man statt IEnumerable<T> die entsprechenden Extension Methods meint 😃