Zwróć wszystkie wyliczalne z wydajnością na raz; bez zapętlania

Mam następującą funkcję, aby uzyskać błędy walidacji karty. Moje pytanie dotyczy radzenia sobie z GetErrors. Obie metody mają ten sam typ zwrotu IEnumerable<ErrorInfo>.

private static IEnumerable<ErrorInfo> GetErrors(Card card)
{
    var errors = GetMoreErrors(card);
    foreach (var e in errors)
        yield return e;

    // further yield returns for more validation errors
}

Czy można zwrócić wszystkie błędy GetMoreErrorsbez konieczności ich wyliczania?

Myśląc o tym, jest to prawdopodobnie głupie pytanie, ale chcę się upewnić, że się nie pomylę.

To zdecydowanie nie jest głupie pytanie i jest to coś, co F # obsługuje yield!dla całej kolekcji w porównaniu yieldz pojedynczym elementem. (Może to być bardzo przydatne w przypadku rekurencji ogonowej ...)

Niestety nie jest obsługiwany w C #.

Jeśli jednak masz kilka metod, z których każda zwraca an IEnumerable<ErrorInfo>, możesz użyć, Enumerable.Concataby uprościć kod:

private static IEnumerable<ErrorInfo> GetErrors(Card card)
{
    return GetMoreErrors(card).Concat(GetOtherErrors())
                              .Concat(GetValidationErrors())
                              .Concat(AnyMoreErrors())
                              .Concat(ICantBelieveHowManyErrorsYouHave());
}

Jest jednak jedna bardzo ważna różnica między tymi dwiema implementacjami: ta wywoła wszystkie metody natychmiast , nawet jeśli będzie używać zwracanych iteratorów tylko po jednej naraz. Twój istniejący kod będzie czekał, aż zostanie zapętlony, GetMoreErrors()zanim zapyta o kolejne błędy.

Zwykle nie jest to ważne, ale warto zrozumieć, co się stanie i kiedy.

Możesz skonfigurować wszystkie źródła błędów w ten sposób (nazwy metod zapożyczone z odpowiedzi Jona Skeeta).

private static IEnumerable<IEnumerable<ErrorInfo>> GetErrorSources(Card card)
{
    yield return GetMoreErrors(card);
    yield return GetOtherErrors();
    yield return GetValidationErrors();
    yield return AnyMoreErrors();
    yield return ICantBelieveHowManyErrorsYouHave();
}

Następnie możesz je powtarzać w tym samym czasie.

private static IEnumerable<ErrorInfo> GetErrors(Card card)
{
    foreach (var errorSource in GetErrorSources(card))
        foreach (var error in errorSource)
            yield return error;
}

Alternatywnie możesz spłaszczyć źródła błędów za pomocą SelectMany.

private static IEnumerable<ErrorInfo> GetErrors(Card card)
{
    return GetErrorSources(card).SelectMany(e => e);
}

Wykonanie metod w również GetErrorSourcesbędzie opóźnione.

Wymyśliłem krótki yield_fragment:

Oto fragment kodu XML:

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Author>John Gietzen</Author>
      <Description>yield! expansion for C#</Description>
      <Shortcut>yield_</Shortcut>
      <Title>Yield All</Title>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal Editable="true">
          <Default>items</Default>
          <ID>items</ID>
        </Literal>
        <Literal Editable="true">
          <Default>i</Default>
          <ID>i</ID>
        </Literal>
      </Declarations>
      <Code Language="CSharp"><![CDATA[foreach (var $i$ in $items$) yield return $i$$end$;]]></Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Nie widzę nic złego w twojej funkcji, powiedziałbym, że robi to, co chcesz.

Pomyśl o Yield jako o zwracaniu elementu w końcowym wyliczeniu za każdym razem, gdy jest on wywoływany, więc jeśli masz go w takiej pętli foreach, za każdym razem, gdy jest wywoływany, zwraca 1 element. Masz możliwość umieszczania instrukcji warunkowych w swoim foreach, aby filtrować zestaw wyników. (po prostu nie poddając się kryteriom wykluczenia)

Jeśli dodasz kolejne plony później w metodzie, będzie on nadal dodawać 1 element do wyliczenia, umożliwiając wykonanie takich czynności jak ...

public IEnumerable<string> ConcatLists(params IEnumerable<string>[] lists)
{
  foreach (IEnumerable<string> list in lists)
  {
    foreach (string s in list)
    {
      yield return s;
    }
  }
}

Jestem zaskoczony, że nikt nie pomyślał o poleceniu prostej metody rozszerzenia, IEnumerable<IEnumerable<T>>aby ten kod zachował odroczone wykonanie. Jestem fanem odroczonego wykonania z wielu powodów, jednym z nich jest to, że ślad pamięci jest niewielki nawet dla ogromnych wyliczeń.

public static class EnumearbleExtensions
{
    public static IEnumerable<T> UnWrap<T>(this IEnumerable<IEnumerable<T>> list)
    {
        foreach(var innerList in list)
        {
            foreach(T item in innerList)
            {
                yield return item;
            }
        }
    }
}

I możesz tego użyć w swoim przypadku w ten sposób

private static IEnumerable<ErrorInfo> GetErrors(Card card)
{
    return DoGetErrors(card).UnWrap();
}

private static IEnumerable<IEnumerable<ErrorInfo>> DoGetErrors(Card card)
{
    yield return GetMoreErrors(card);

    // further yield returns for more validation errors
}

Podobnie możesz pozbyć się funkcji opakowującej DoGetErrorsi po prostu przejść UnWrapdo callsite.

Tak, istnieje możliwość natychmiastowego zwrócenia wszystkich błędów. Po prostu zwróć List<T>lub ReadOnlyCollection<T>.

Zwracając IEnumerable<T>i zwracasz sekwencję czegoś. Na pozór może wydawać się to identyczne jak zwrot kolekcji, ale istnieje kilka różnic, o których należy pamiętać.

Kolekcje

• Wzywający może być pewien, że zarówno kolekcja, jak i wszystkie elementy będą istniały, gdy kolekcja zostanie zwrócona. Jeśli kolekcja musi zostać utworzona na wywołanie, zwracanie kolekcji jest naprawdę złym pomysłem.
• Większość kolekcji można zmodyfikować po zwróceniu.
• Kolekcja ma ograniczony rozmiar.

Sekwencje

• Można to wyliczyć - i to prawie wszystko, co możemy powiedzieć na pewno.
• Zwracanej sekwencji nie można modyfikować.
• Każdy element może zostać utworzony jako część przebiegu sekwencji (tj. Zwracanie IEnumerable<T>pozwala na leniwą ocenę, a zwracanie List<T>nie).
• Sekwencja może być nieskończona, dlatego wywołującemu należy pozostawić decyzję, ile elementów ma zostać zwróconych.