为什么Iterable< T>不提供stream（）和parallelStream（）方法？ [英] Why does Iterable<T> not provide stream() and parallelStream() methods?

问题描述

我想知道为什么 Iterable 界面不提供 stream（）和 parallelStream（）方法。考虑以下类：

I am wondering why the Iterable interface does not provide the stream() and parallelStream() methods. Consider the following class:

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();
    }
}

这是 Hand <的实现/ em>因为你可以在玩交易卡游戏时拿到牌。

It is an implementation of a Hand as you can have cards in your hand while playing a Trading Card Game.

基本上它包裹了列表<卡> ，确保最大容量并提供一些其他有用的功能。最好直接将其作为 List< Card> 实施。

Essentially it wraps a List<Card>, ensures a maximum capacity and offers some other useful features. It is better as implementing it directly as a List<Card>.

现在，为了方便起见，我认为它会很高兴实现 Iterable< Card> ，这样如果你想循环它就可以使用增强的for循环。 （我的 Hand 类还提供 get（int index）方法，因此 Iterable<在我看来，卡> 是合理的。）

Now, for convienience I thought it would be nice to implement Iterable<Card>, such that you can use enhanced for-loops if you want to loop over it. (My Hand class also provides a get(int index) method, hence the Iterable<Card> is justified in my opinion.)

Iterable 界面提供以下内容（省略javadoc）：

The Iterable interface provides the following (left out 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);
    }
}

现在可以获得一个包含以下内容的流：

Now can you obtain a stream with:

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

所以真正的问题：

• 为什么 Iterable< T> 不提供实现 stream（）的默认方法 parallelStream（），我什么都看不到会造成这种不可能或不需要的东西？

• Why does Iterable<T> not provide a default methods that implement stream() and parallelStream(), I see nothing that would make this impossible or unwanted?

我发现的一个相关问题如下：为什么Stream< T>没有实现Iterable< T>？

奇怪的是，建议它在某种程度上相反。

A related question I found is the following though: Why does Stream<T> not implement Iterable<T>?
Which is oddly enough suggesting it to do it somewhat the other way around.

推荐答案

这不是遗漏; 2013年6月对EG清单进行了详细讨论。

This was not an omission; there was detailed discussion on the EG list in June of 2013.

专家组的最终讨论植根于这个主题。

The definitive discussion of the Expert Group is rooted at this thread.

虽然它似乎明显的（甚至对专家组来说，最初） stream（）似乎在 Iterable 上有意义，事实那个 Iterable 如此普遍成为一个问题，因为明显的签名：

While it seemed "obvious" (even to the Expert Group, initially) that stream() seemed to make sense on Iterable, the fact that Iterable was so general became a problem, because the obvious signature:

Stream<T> stream()

并不总是你想要的。例如，某些 Iterable< Integer> 的内容宁愿让他们的stream方法返回 IntStream 。但是将 stream（）方法放在层次结构中的高位会使这变得不可能。因此，我们通过提供 Iterable 制作 Stream 非常容易> spliterator（）方法。在 Collection 中实现 stream（）只是：

was not always what you were going to want. Some things that were Iterable<Integer> would rather have their stream method return an IntStream, for example. But putting the stream() method this high up in the hierarchy would make that impossible. So instead, we made it really easy to make a Stream from an Iterable, by providing a spliterator() method. The implementation of stream() in Collection is just:

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

任何客户都可以从获得他们想要的流Iterable with：

Any client can get the stream they want from an Iterable with:

Stream s = StreamSupport.stream(iter.spliterator(), false);

最后我们得出结论，添加 stream（）到 Iterable 将是一个错误。

In the end we concluded that adding stream() to Iterable would be a mistake.

这篇关于为什么Iterable&lt; T&gt;不提供stream（）和parallelStream（）方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！