Pourquoi ne Itérable<T> ne pas fournir de stream() et parallelStream() méthodes?

Je me demande pourquoi le Iterable interface ne permet pas de fournir les stream() et parallelStream() méthodes. Considérons la classe suivante:

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

    //...

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

C'est une mise en œuvre d'un Main que vous pouvez avoir des cartes dans votre main tout en jouant à un Jeu de Cartes à collectionner.

Essentiellement, il enroule une List<Card>, assure un maximum de capacité et offre d'autres fonctionnalités utiles. C'est mieux que de mettre en œuvre directement comme un List<Card>.

Maintenant, pour convienience j'ai pensé qu'il serait bien de mettre en œuvre Iterable<Card>, de sorte que vous pouvez utiliser renforcée pour boucles si vous souhaitez faire une boucle sur elle. (Mon Hand de la classe fournit également un get(int index) méthode, d'où le Iterable<Card> est justifié à mon avis.)

La Iterable interface fournit les suivantes (à gauche en sortant de javadoc):

public interface Iterable<T> {
    Iterator<T> iterator();

    default void forEach(Consumer<? super T> action) {
        Objects.requireNonNull(action);
        for (T t : this) {
            action.accept(t);
        }
    }

    default Spliterator<T> spliterator() {
        return Spliterators.spliteratorUnknownSize(iterator(), 0);
    }
}

Maintenant, pouvez-vous obtenir un flux avec:

Stream<Hand> stream = StreamSupport.stream(hand.spliterator(), false);

Donc sur la vraie question:

Pourquoi ne Iterable<T> pas fournir une valeur par défaut des méthodes qui mettent en œuvre des stream() et parallelStream(), je ne vois rien qui pourrait la rendre impossible ou indésirable?

Une question connexe, j'ai trouvé est la suivante si: Pourquoi ne Stream<T> ne pas mettre en œuvre Itérable<T>?

Qui est curieusement il suggère de faire un peu l'inverse.

Je suppose que c'est une bonne question, pour le Lambda Liste de Diffusion.
Pourquoi est-il étrange de vouloir effectuer une itération sur un stream? Sinon, comment pourriez-vous éventuellement break; une itération? (Ok, Stream.findFirst() pourrait être une solution, mais ça pourrait ne pas répondre à tous les besoins...)
Voir aussi Convertir en objet iterable de Flux à l'aide de Java JDK 8 pour la pratique de solutions de contournement.

InformationsquelleAutor skiwi | 2014-04-16

java java-8

280

Ce n'était pas une omission; il y avait une discussion détaillée sur le EG liste au mois de juin 2013.

La discussion définitive du Groupe d'Experts est lié à ce fil.

Alors qu'il semblait "évident" (même pour le Groupe d'Experts, d'abord) que stream() semblait faire sens sur Iterable, le fait que Iterable était si général est devenu un problème, parce que l'évidence de la signature:
```
Stream<T> stream()
```
n'était pas toujours ce que vous allez vouloir. Certaines choses qui ont été Iterable<Integer> serait plutôt de leur flux de retour de méthode un IntStream, par exemple. Mais de la mise stream() méthode de ce haut dans la hiérarchie de la rendrait impossible. Donc, au lieu de cela, nous avons fait c'est vraiment facile de faire une Stream à partir d'un Iterable, en fournissant un spliterator() méthode. La mise en œuvre de stream() dans Collection est juste:
```
default Stream<E> stream() {
    return StreamSupport.stream(spliterator(), false);
}
```
Tout client peut obtenir le flux qu'ils veulent à partir d'un Iterable avec:
```
Stream s = StreamSupport.stream(iter.spliterator(), false);
```
À la fin, nous avons conclu que l'ajout de stream() à Iterable serait une erreur.
- Je vois, tout d'abord, merci beaucoup pour répondre à la question. Je suis toujours curieux mais pourquoi un Iterable<Integer> (je pense que vous êtes en train de parler?) souhaitez retourner un IntStream. Serait l'objet iterable alors pas plutôt un PrimitiveIterator.OfInt? Ou avez-vous peut-être dire un autre cas d'utilisation?
- Peut-être, mais vous ne savez pas vraiment qui soit. Itérable est trop général; par défaut, les méthodes que nous ajoutons à Itérable implicitement contraint le contrat de Itérable (pire, après le fait). Nous avons fait, il est facile d'obtenir un flux de données à partir d'un objet iterable, en exposant spliterator() (qui est une généralisation de l'Itérateur, donc ce n'est pas beaucoup d'un tronçon.) Mais la prudence dicte de nous arrêter là.
- Juste à noter que le dernier exemple de code ne compile pas AFAICT. Le fournisseur variation prend trois arguments, pas un seul.
- Je trouve bizarre que la logique ci-dessus aurait été appliquée à Itérable (je ne peux pas stream() parce que quelqu'un pourrait vouloir revenir IntStream), tandis qu'une quantité égale de pensée n'est pas donné à ajouter exactement la même méthode de Collecte (que je veuille ma Collection<Integer>'s stream() pour retourner IntStream aussi.) S'il était présent sur les deux ou absentes sur les deux, les gens auraient probablement obtenu simplement avec leur vie, mais parce qu'il est présent sur l'un et en l'absence de l'autre, il devient tout à fait un oubli flagrant...
- La Composition au cours de l'héritage.
- Pourquoi ne pas Iterable ont stream(), puis les développeurs peuvent ajouter intStream() le cas échéant? Aussi, je soupçonne le cas où le problème que vous décrivez serait de se produire sont rares.
- Brian McCutchon: cela fait plus de sens pour moi. Cela ressemble à des personnes juste eu marre d'argumenter et a décidé de jouer la sécurité.
- Tout cela a un sens, est-il une raison pourquoi il n'y a pas une alternative statique Stream.of(Iterable), ce qui permettrait au moins de faire de la méthode raisonnablement identifiable par la lecture de la documentation de l'API -- comme de quelqu'un qui n'a jamais vraiment travaillé avec le fonctionnement interne de Flux, je n'avais même jamais regardé à StreamSupport, qui est décrit dans la documentation comme les opérations de bas niveau", qui sont "principalement pour la bibliothèque des écrivains".
- Je suis totalement d'accord avec Jules. une méthode statique de Flux.de(Iteratable iter) ou d'un Ruisseau.de(Iterator iter) doit être ajoutée, au lieu de StreamSupport.flux(iter.spliterator(), false);
- D'accord avec Jules, Brian M., skiwi, et user_3380739 -- comme quelqu'un de revenir à Java après de nombreux, de nombreuses années de C#, cela semble être une omission évidente. Aussi, spliterator -- sérieusement, qu'est ce que ça s'appelle? Sonne comme une 3ème partie de la bibliothèque JS pour moi!
- Pourquoi ne java.util.stream et java.util.function ont un traitement spécial pour les primitives? Nous avons IntStream et IntUnaryOperator etc. mais pas IntList ou IntIterable etc. Alors il n'y aurait pas le problème de Iterable<Integer> vouloir IntStream type de retour.
InformationsquelleAutor Brian Goetz
23

J'ai fait une enquête dans plusieurs de le projet lambda listes de diffusion, et je crois que j'ai trouvé quelques discussions intéressantes.

Je n'ai pas trouvé d'explication satisfaisante à ce jour. Après la lecture de tout cela, je conclus que c'était juste une omission. Mais vous pouvez voir ici qu'il a été évoqué à plusieurs reprises au fil des ans lors de la conception de l'API.

Lambda Libs Spec Experts

J'ai trouvé une discussion à ce sujet dans le Lambda Libs Spec Experts de la liste de diffusion:

Sous Itérable/Itérateur.stream() Sam Pullara dit:

J'ai travaillé avec Brian de voir comment limiter/sous-flux
la fonctionnalité[1] peut être mis en œuvre et il a suggéré de conversion
Itérateur est la bonne façon d'aller à ce sujet. J'avais pensé que
solution mais ne trouve pas de moyen évident de prendre un itérateur et tourner à
dans un flux. Il s'avère qu'il est là, vous avez juste besoin d'abord de
convertir l'itérateur à un spliterator et puis convertir le spliterator
à un ruisseau. Ceci m'amène donc à revisiter la question de savoir si nous devrions avoir
ces accroché à un de Itératif/Itérateur directement ou deux.

Ma suggestion est d'au moins l'avoir sur Itérateur de sorte que vous pouvez déplacer
proprement entre les deux mondes, et il serait aussi facilement
détectable plutôt que d'avoir à faire:

Ruisseaux.flux(Spliterators.spliteratorUnknownSize(itérateur,
Spliterator.COMMANDÉ))

Et puis Brian Goetz a répondu:

Je pense que Sam a que il ya beaucoup de bibliothèque de classes
vous donner un Itérateur, mais ne vous laisseront pas nécessairement écrire votre propre
spliterator. Donc, tout ce que vous pouvez faire est d'appeler
flux(spliteratorUnknownSize(itérateur)). Sam suggère que nous
définir Itérateur.stream() pour le faire pour vous.

Je tiens à garder le flux() et spliterator() méthodes comme étant
pour la bibliothèque des écrivains /les utilisateurs avancés.

Et plus tard

"Étant donné que la rédaction d'une Spliterator est plus facile que d'écrire un Itérateur,
Je préfère juste écrire un Spliterator au lieu d'un Itérateur (Itérateur est tellement années 90 :)"

Vous êtes à côté de la question, mais. Il y a des millions de ces classes
il y a que déjà main que vous avez un Itérateur. Et beaucoup d'entre eux ne sont pas
spliterator-prêt.

De Délibérations antérieures Lambda Liste de Diffusion

Cela peut ne pas être la réponse que vous cherchez, mais dans le Projet Lambda liste de diffusion cela a été brièvement abordée. Peut-être ce qui contribue à favoriser une discussion plus large sur le sujet.

Dans les paroles de Brian Goetz sous Les flux de Itérable:

Reculer d'un pas...

Il y a beaucoup de façons de créer un Flux. Le plus d'informations que vous
ont sur la façon de décrire les éléments, le plus de fonctionnalités et
performance le flux de la bibliothèque peut vous donner. Dans l'ordre de moins de
la plupart des informations, ils sont:

Itérateur

Itérateur + taille

Spliterator

Spliterator qui sait que sa taille

Spliterator qui sait que sa taille, et encore sait que tous les sous-groupes
connaître leur taille.

(Certains peuvent être surpris de découvrir que nous pouvons extraire le parallélisme de même
à partir d'un muet itérateur dans les cas où Q (par élément)
non triviaux.)

Si Itérable avait un courant() la méthode, il suffit de l'envelopper d'un Itérateur
un Spliterator, avec n la taille de l'information. Mais, la plupart des choses qui sont
Itérable ne avoir des informations sur la taille. Ce qui signifie que nous sommes de servir
déficientes en flux. Ce n'est pas si bon.

Un inconvénient de l'API de la pratique décrite par Stephen ici, de
accepter Itérable au lieu de la Collecte, c'est que vous êtes forçant
les choses à travers un "petit tuyau" et, par conséquent, rejeter la taille
d'information lorsque cela peut être utile. C'est très bien si tout ce que vous faites
à faire est de forEach, mais si vous voulez faire plus, son meilleur si vous
peut conserver tous les renseignements que vous souhaitez.

La valeur par défaut fournie par Itérable serait une merde, en effet, -- il
serait jeter la taille, même si la grande majorité des Iterables ne sais
que de l'information.

Contradiction?

Bien, il semble que la discussion est basée sur les modifications que le Groupe d'Experts n', la conception initiale de cours d'eau qui a d'abord été fondée sur les itérateurs.

Même ainsi, il est intéressant de remarquer que, dans une interface comme la Collecte, le flux de la méthode est définie comme:
```
default Stream<E> stream() {
    return StreamSupport.stream(spliterator(), false);
}
```
Qui pourrait être exactement le même code utilisé dans l'Itérable interface.

Donc, c'est pourquoi j'ai dit que cette réponse n'est probablement pas satisfaisante, mais tout de même intéressants pour la discussion.

Preuve de Refactoring

Continue avec l'analyse de la liste de diffusion, il semble que la splitIterator méthode a été à l'origine dans la Collection de l'interface, et à un certain moment en 2013, ils se sont déplacés jusqu'à Itératif.

Pull splitIterator en place de la Collecte à l'Itérable.

Conclusion/Théories?

Alors les chances sont que le manque de méthode dans l'objet iterable est juste une omission, car on dirait qu'ils devraient avoir déplacé le flux de la méthode ainsi quand ils ont déménagé de la splitIterator en place de la Collecte à l'Itératif.

Si il y a d'autres raisons de ceux qui ne sont pas évidents. Quelqu'un d'autre a d'autres théories?
- Je vous remercie de votre réponse, mais je suis en désaccord avec le raisonnement là. Au moment de remplacer le spliterator() de la Iterable, alors tous les problèmes sont résolus, et vous pouvez trivialement mettre en œuvre stream() et parallelStream()..
- C'est pourquoi j'ai dit que ce n'est probablement pas la réponse. Je suis juste essayer d'ajouter à la discussion, car il est difficile de savoir pourquoi le groupe d'experts a pris les décisions qu'ils ont fait. Je suppose que tout ce que nous pouvons faire est d'essayer de faire un peu d'investigation dans la liste de diffusion et de voir si nous pouvons venir avec de raisons.
- J'ai passé en revue d'autres listes de diffusion, et trouvé plus de preuves pour la discussion et peut-être quelques idées qui aideront à formuler l'hypothèse d'un diagnostic.
- Merci pour vos efforts, je devrais vraiment apprendre à diviser par le biais de ces listes de diffusion. Il serait utile si ils pourraient être visualisées dans certains... d'une façon moderne, comme un forum ou quelque chose, parce que la lecture d'emails en texte brut avec des citations n'est pas vraiment efficace.
InformationsquelleAutor Edwin Dalorzo
6

Si vous connaissez la taille que vous pourriez utiliser java.util.Collection qui fournit le stream() méthode:
```
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();
   }
}
```
Et puis:
```
new Hand().stream().map(...)
```
J'ai connu le même problème et a été surpris de voir que mon Iterable mise en œuvre pourrait très facilement être étendu à un AbstractCollection mise en œuvre en ajoutant simplement le size() méthode (heureusement, j'avais la taille de la collection 🙂

Vous devriez également envisager de remplacer Spliterator<E> spliterator().

InformationsquelleAutor Udo

Vous devez vous connecter pour publier un commentaire.