Dlaczego Iterable nie dostarcza metod stream () i parallelStream ()?

Przeprowadziłem dochodzenie na kilku listach dyskusyjnych projektu lambda i myślę, że znalazłem kilka ciekawych dyskusji.

Lambda Libs Spec Experts

Znalazłem dyskusję na ten temat w Lambda Libs Spec Experts mailingu lista :

Pod Iterable / Iterator.stream() sam Pullara powiedział:

Pracowałam z Brianem nad tym, jak limit / substream funkcjonalność [1] może być zaimplementowana i zaproponował konwersję do Iterator był dobrym rozwiązaniem. Myślałem o tym. rozwiązanie, ale nie znalazł żadnego oczywistego sposobu, aby wziąć iterator i włączyć do strumienia. Okazuje się, że jest tam, trzeba tylko najpierw przekształcić iterator na spliterator, a następnie Konwertuj spliterator do strumienia. Więc to sprowadza mnie do ponownego zastanowienia się, czy powinniśmy mieć te zwisające z jednego z Iterable / Iterator bezpośrednio lub oba.

Moja sugestia to przynajmniej mieć go na Iteratorze, więc można przenieść czysto między dwoma światami i byłoby to również łatwe odkrywalne zamiast robić:

Strumienie.strumień(bułg.spliteratorUnknownSize(iterator, Spliterator.Uporządkowane))

A potem Brian Goetz odpowiedź :

Myślę, że chodzi o to, że jest wiele klas bibliotecznych, które dać iteratora, ale nie pozwól koniecznie napisać własnego spliterator. Więc wszystko, co możesz zrobić, to zadzwonić stream(spliteratorUnknownSize (iterator)). Sam sugeruje, że zdefiniuj Iterator.stream (), aby zrobić to za Ciebie.

Chciałbym, aby metody stream() i spliterator() były dla autorów bibliotek / zaawansowanych użytkowników.

Oraz później

"biorąc pod uwagę, że pisanie Spliteratora jest łatwiejsze niż pisanie iteratora, Wolałbym po prostu napisać Spliterator zamiast iteratora (Iterator jest taki 90s :) "

Ale nie rozumiesz. Są miliony zajęć tam, żejuż dać Ci Iterator. A wielu z nich nie jest spliterator gotowy.

Poprzednie dyskusje na liście dyskusyjnej Lambda

To może nie być odpowiedź jesteś szukając ale w projekt lambda lista dyskusyjna to było krótko omówione. Być może przyczyni się to do szerszej dyskusji na ten temat.

W słowach Briana Goetza pod strumienie z Iterable :

Cofam się... Istnieje wiele sposobów tworzenia strumienia. Im więcej informacji mają o tym, jak opisać elementy, więcej funkcjonalności i wydajność, którą może Ci dać biblioteka strumieni. W kolejności najmniejszej na większość informacji to:

Iterator

Iterator + Rozmiar

Spliterator

Spliterator, który zna swój rozmiar

Spliterator, który zna swój rozmiar, a ponadto wie, że wszystkie sub-Splitty poznaj ich rozmiar.

(niektórzy mogą się dziwić, że możemy wyodrębnić równoległość nawet z durnego iteratora w przypadkach, gdy Q (praca na element) jest nietrywialne.)

Jeśli Iterable ma metodę stream (), to po prostu zawija Iterator z Spliterator, bez informacji o rozmiarze. Ale większość rzeczy, które są Iterabledo mają informacje o rozmiarze. Co oznacza, że serwujemy deficytowe strumienie. Nie za dobrze.

Jedną z wad praktyki API opisanej przez Stephena tutaj, z akceptując Iterable zamiast Collection, jest to, że wymuszasz rzeczy przez "małą rurę", a zatem odrzucenie wielkości informacje, kiedy mogą być przydatne. To dobrze, jeśli wszystko, co robisz na zrobić jest forEach to, ale jeśli chcesz zrobić więcej, to lepiej, jeśli może zachować wszystkie potrzebne informacje.

Domyślna wartość dostarczana przez Iterable byłaby naprawdę beznadziejna -- to odrzuciłoby rozmiar, mimo że zdecydowana większość Iterabli wie ta informacja.

Sprzeczność?

Chociaż wygląda na to, że dyskusja opiera się na zmianach, które grupa ekspertów zrobiła w początkowym projekcie strumieni, który początkowo opierał się na Iteratory.

Mimo to, warto zauważyć, że w interfejsie takim jak Collection, metoda stream jest zdefiniowana jako:

default Stream<E> stream() {
   return StreamSupport.stream(spliterator(), false);
}

Co może być dokładnie tym samym kodem używanym w iterowalnym interfejsie.

Dlatego powiedziałem, że ta odpowiedź prawdopodobnie nie jest zadowalająca, ale nadal ciekawa do dyskusji.

Dowód refaktoryzacji

Kontynuując analizę na liście dyskusyjnej, wygląda na to, że metoda splitIterator była początkowo w interfejsie kolekcji, a w pewnym momencie w 2013 roku przenieśli go do Iterable.

Pull splitIterator up from Collection to Iterable .

Wnioski/Teorie?

Wtedy są szanse, że brak metody w Iterable jest tylko pominięciem, ponieważ wygląda na to, że powinni byli przenieść metodę stream, jak również, gdy przenieśli splitIterator z kolekcji do Iterable.

Jeśli są inne powody, nie są one oczywiste. Ktoś jeszcze ma inne teorie?

Jeśli znasz rozmiar, możesz użyć java.util.Collection, który zapewnia metodę stream():

public class Hand extends AbstractCollection<Card> {
   private final List<Card> list = new ArrayList<>();
   private final int capacity;

   //...

   @Override
   public Iterator<Card> iterator() {
       return list.iterator();
   }

   @Override
   public int size() {
      return list.size();
   }
}

A następnie:

new Hand().stream().map(...)

Spotkałem się z tym samym problemem i byłem zaskoczony, że moja implementacja Iterable może być bardzo łatwo rozszerzona do AbstractCollection poprzez dodanie metody size() (na szczęście miałem rozmiar kolekcji: -)

Należy również rozważyć nadpisanie Spliterator<E> spliterator().