Dlaczego w IEnumerable nie ma metody rozszerzenia ForEach?

Zainspirowany innym pytaniem dotyczącym brakującej Zipfunkcji:

Dlaczego ForEachw Enumerableklasie nie ma metody rozszerzenia ? Czy gdziekolwiek? Jedyną klasą, która otrzymuje ForEachmetodę, jest List<>. Czy istnieje powód, dla którego go brakuje (wydajność)?

W języku, który wykonuje pracę przez większość czasu, jest już zawarte zdanie foreach.

Nie chciałbym widzieć następujących rzeczy:

list.ForEach( item =>
{
    item.DoSomething();
} );

Zamiast:

foreach(Item item in list)
{
     item.DoSomething();
}

Ten ostatni jest bardziej przejrzysty i łatwiejszy do odczytania w większości sytuacji , choć może trochę dłużej pisać.

Muszę jednak przyznać, że zmieniłem stanowisko w tej sprawie; metoda rozszerzenia ForEach () rzeczywiście byłaby przydatna w niektórych sytuacjach.

Oto główne różnice między instrukcją a metodą:

• Sprawdzanie typu: foreach odbywa się w czasie wykonywania, ForEach () jest w czasie kompilacji (Big Plus!)
• Składnia wywołania delegata jest w rzeczywistości o wiele prostsza: objects.ForEach (DoSomething);
• ForEach () można powiązać: chociaż zło / użyteczność takiej funkcji jest otwarta do dyskusji.

To wszystko są świetne uwagi wielu ludzi tutaj i rozumiem, dlaczego ludzie tęsknią za tą funkcją. Nie miałbym nic przeciwko dodaniu przez Microsoft standardowej metody ForEach w następnej iteracji frameworka.

Metoda ForEach została dodana przed LINQ. Jeśli dodasz rozszerzenie ForEach, nigdy nie będzie ono wywoływane dla instancji List z powodu ograniczeń metod rozszerzenia. Myślę, że powodem, dla którego nie został dodany, jest brak ingerencji w istniejącą.

Jeśli jednak naprawdę tęsknisz za tą małą fajną funkcją, możesz wypuścić własną wersję

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

Możesz napisać tę metodę rozszerzenia:

// Possibly call this "Do"
IEnumerable<T> Apply<T> (this IEnumerable<T> source, Action<T> action)
{
    foreach (var e in source)
    {
        action(e);
        yield return e;
    }
}

Plusy

Pozwala na łączenie:

MySequence
    .Apply(...)
    .Apply(...)
    .Apply(...);

Cons

W rzeczywistości nic nie zrobi, dopóki nie zrobisz czegoś, aby wymusić iterację. Z tego powodu nie należy go nazywać .ForEach(). Możesz napisać .ToList()na końcu lub możesz również napisać tę metodę rozszerzenia:

// possibly call this "Realize"
IEnumerable<T> Done<T> (this IEnumerable<T> source)
{
    foreach (var e in source)
    {
        // do nothing
        ;
    }

    return source;
}

Może to być zbyt znaczące odstępstwo od wysyłanych bibliotek C #; czytelnicy, którzy nie znają metod rozszerzenia, nie będą wiedzieli, co zrobić z twoim kodem.

Dyskusja tutaj daje odpowiedź:

Właściwie konkretna dyskusja, której byłem świadkiem, w rzeczywistości zależała od czystości funkcjonalnej. W wyrażeniu często przyjmuje się założenia, że ​​nie ma skutków ubocznych. Posiadanie ForEach to raczej zachęcanie do skutków ubocznych niż tylko znoszenie ich. - Keith Farmer (partner)

Zasadniczo podjęto decyzję o tym, aby metody rozszerzenia były funkcjonalnie „czyste”. ForEach zachęcałby do skutków ubocznych przy stosowaniu metod rozszerzania Enumerable, co nie było zamierzone.

Chociaż zgadzam się, że lepiej jest używać wbudowanej foreachkonstrukcji w większości przypadków, uważam, że użycie tej odmiany rozszerzenia ForEach <> jest nieco przyjemniejsze niż samodzielne zarządzanie indeksem foreach:

public static int ForEach<T>(this IEnumerable<T> list, Action<int, T> action)
{
    if (action == null) throw new ArgumentNullException("action");

    var index = 0;

    foreach (var elem in list)
        action(index++, elem);

    return index;
}

var people = new[] { "Moe", "Curly", "Larry" };
people.ForEach((i, p) => Console.WriteLine("Person #{0} is {1}", i, p));

Dałby ci:

Person #0 is Moe
Person #1 is Curly
Person #2 is Larry

Jednym obejściem jest napisanie .ToList().ForEach(x => ...).

profesjonaliści

Łatwy do zrozumienia - czytelnik musi tylko wiedzieć, co jest dostarczane z C #, a nie żadnych dodatkowych metod rozszerzenia.

Szum syntaktyczny jest bardzo łagodny (dodaje tylko trochę ekstrawaganckiego kodu).

Zwykle nie kosztuje to dodatkowej pamięci, ponieważ natywny i .ForEach()tak musiałby zrealizować całą kolekcję.

Cons

Kolejność operacji nie jest idealna. Wolę zdać sobie sprawę z jednego elementu, a następnie zastosować go, a następnie powtórzyć. Ten kod najpierw realizuje wszystkie elementy, a następnie działa na nie kolejno.

Jeśli realizacja listy spowoduje wyjątek, nigdy nie będziesz działać na jednym elemencie.

Jeśli wyliczenie jest nieskończone (jak liczby naturalne), nie masz szczęścia.

Zawsze się nad tym zastanawiałem, dlatego zawsze noszę to ze sobą:

public static void ForEach<T>(this IEnumerable<T> col, Action<T> action)
{
    if (action == null)
    {
        throw new ArgumentNullException("action");
    }
    foreach (var item in col)
    {
        action(item);
    }
}

Fajna mała metoda rozszerzenia.

Pojawiło się wiele komentarzy na temat tego, że metoda rozszerzenia ForEach nie jest odpowiednia, ponieważ nie zwraca wartości takiej jak metody rozszerzenia LINQ. Chociaż jest to stwierdzenie oparte na faktach, nie jest ono do końca prawdą.

Wszystkie metody rozszerzenia LINQ zwracają wartość, dzięki czemu można je połączyć w łańcuch:

collection.Where(i => i.Name = "hello").Select(i => i.FullName);

Jednak fakt, że LINQ jest implementowany przy użyciu metod rozszerzenia, nie oznacza, że ​​metody rozszerzenia muszą być używane w ten sam sposób i zwracają wartość. Pisanie metody rozszerzenia w celu ujawnienia wspólnej funkcjonalności, która nie zwraca wartości, jest całkowicie poprawnym zastosowaniem.

Konkretny argument dotyczący ForEach polega na tym, że w oparciu o ograniczenia dotyczące metod rozszerzenia (a mianowicie, że metoda rozszerzenia nigdy nie zastąpi odziedziczonej metody o tej samej sygnaturze ), może wystąpić sytuacja, w której niestandardowa metoda rozszerzenia jest dostępna we wszystkich klasach, które stymulują IEnumerable <T> oprócz List <T>. Może to powodować zamieszanie, gdy metody zaczną zachowywać się inaczej, w zależności od tego, czy wywoływana jest metoda rozszerzenia, czy metoda dziedziczenia.

Możesz użyć (łańcuchowy, ale leniwie oceniany) Select, najpierw wykonując operację, a następnie zwracając tożsamość (lub coś innego, jeśli wolisz)

IEnumerable<string> people = new List<string>(){"alica", "bob", "john", "pete"};
people.Select(p => { Console.WriteLine(p); return p; });

Będziesz musiał upewnić się, że nadal jest oceniany, za pomocą Count()(najtańszej operacji do wyliczenia afaik) lub innej operacji, której i tak potrzebujesz.

Chciałbym jednak, aby został on wprowadzony do standardowej biblioteki:

static IEnumerable<T> WithLazySideEffect(this IEnumerable<T> src, Action<T> action) {
  return src.Select(i => { action(i); return i; } );
}

Powyższy kod staje się wtedy people.WithLazySideEffect(p => Console.WriteLine(p))faktycznie równoważny z foreach, ale leniwy i możliwy do połączenia.

Zauważ, że MoreLINQ NuGet zapewnia ForEachmetodę rozszerzenia, której szukasz (a także Pipemetodę, która wykonuje przekazanie i daje wynik). Widzieć:

• https://www.nuget.org/packages/morelinq
• https://code.google.com/p/morelinq/wiki/OperatorsOverview

@Coincoin

Prawdziwa siła metody rozszerzenia foreach polega na możliwości ponownego użycia Action<>bez dodawania niepotrzebnych metod do kodu. Powiedz, że masz 10 list i chcesz wykonywać na nich tę samą logikę, a odpowiednia funkcja nie pasuje do twojej klasy i nie jest ponownie używana. Zamiast mieć dziesięć dla pętli lub funkcję ogólną, która jest oczywiście pomocnikiem, który nie należy, możesz zachować całą logikę w jednym miejscu ( Action<>. Tak więc, dziesiątki linii zastępuje się

Action<blah,blah> f = { foo };

List1.ForEach(p => f(p))
List2.ForEach(p => f(p))

itp...

Logika jest w jednym miejscu i nie zanieczyściłeś swojej klasy.

Większość metod rozszerzenia LINQ zwraca wyniki. ForEach nie pasuje do tego wzoru, ponieważ nic nie zwraca.

Jeśli masz F # (który będzie w następnej wersji .NET), możesz użyć

Seq.iter doSomething myIEnumerable

Częściowo dzieje się tak, ponieważ projektanci języków nie zgadzają się z tym z filozoficznego punktu widzenia.

• Brak posiadania (i testowanie ...) funkcji jest mniej pracy niż posiadanie funkcji.
• Nie jest tak naprawdę krótszy (istnieją pewne przypadki funkcji przechodzących, ale nie byłoby to podstawowe zastosowanie).
• Jego celem jest wywoływanie skutków ubocznych, a nie o to chodzi w Linq.
• Dlaczego mamy inny sposób na zrobienie tego samego, co funkcja, którą już mamy? (każde słowo kluczowe)

https://blogs.msdn.microsoft.com/ericlippert/2009/05/18/foreach-vs-foreach/

Możesz użyć opcji select, gdy chcesz coś zwrócić. Jeśli tego nie zrobisz, możesz najpierw użyć ToList, ponieważ prawdopodobnie nie chcesz niczego modyfikować w kolekcji.

Napisałem o tym post na blogu: http://blogs.msdn.com/kirillosenkov/archive/2009/01/31/foreach.aspx

Możesz głosować tutaj, jeśli chcesz zobaczyć tę metodę w .NET 4.0: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=279093

W wersji 3.5 wszystkie metody rozszerzeń dodane do IEnumerable są dostępne dla obsługi LINQ (zauważ, że są one zdefiniowane w klasie System.Linq.Enumerable). W tym poście wyjaśniam, dlaczego foreach nie należy do LINQ: istniejąca metoda rozszerzenia LINQ podobna do Parallel.For?

Czy to ja, czy lista <T>. Poszukiwania zostały prawie całkowicie przestarzałe przez Linq. Pierwotnie było

foreach(X x in Y) 

gdzie Y po prostu musiał być IEnumerable (Pre 2.0) i zaimplementować GetEnumerator (). Jeśli spojrzysz na wygenerowany MSIL, zobaczysz, że jest dokładnie taki sam jak

IEnumerator<int> enumerator = list.GetEnumerator();
while (enumerator.MoveNext())
{
    int i = enumerator.Current;

    Console.WriteLine(i);
}

(Zobacz http://alski.net/post/0a-for-foreach-forFirst-forLast0a-0a-.aspx dla MSIL)

Następnie w DotNet2.0 pojawiła się Generics i Lista. Foreach zawsze uważał mnie za implementację wzorca Vistora (patrz Wzory projektowe Gamma, Helm, Johnson, Vlissides).

Teraz oczywiście w wersji 3.5 możemy zamiast tego użyć Lambdy do tego samego efektu, na przykład spróbuj http://dotnet-developments.blogs.techtarget.com/2008/09/02/iterators-lambda-and-linq-oh- mój/

Chciałbym rozwinąć odpowiedź Aku .

Jeśli chcesz wywołać metodę wyłącznie w celu uzyskania efektu ubocznego bez iteracji najpierw całej liczby, możesz użyć tego:

private static IEnumerable<T> ForEach<T>(IEnumerable<T> xs, Action<T> f) {
    foreach (var x in xs) {
        f(x); yield return x;
    }
}

Nikt jeszcze nie zauważył, że ForEach <T> powoduje sprawdzenie typu czasu kompilacji, w którym sprawdzane jest słowo kluczowe foreach.

Po dokonaniu refaktoryzacji w przypadku użycia obu metod w kodzie, faworyzuję .ForEach, ponieważ musiałem wyłapać błędy testowe / błędy w czasie wykonywania, aby znaleźć problemy z Foreach.