为什么 Iterable<T> 不提供 stream() 和 parallelStream() 方法？答案

【问题标题】：Why does Iterable<T> not provide stream() and parallelStream() methods?为什么 Iterable<T> 不提供 stream() 和 parallelStream() 方法？
【发布时间】：2014-05-31 14:18:04
【问题描述】：

我想知道为什么Iterable 接口不提供stream() 和parallelStream() 方法。考虑以下类：

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的一种实现，因为您可以在玩集换式卡牌游戏时手中有牌。

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

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

Iterable 接口提供以下内容（省略 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);
    }
}

现在你可以获得一个流：

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

所以到真正的问题：

为什么Iterable<T> 不提供实现stream() 和parallelStream() 的默认方法，我看不出这不可能或不需要？

我发现的一个相关问题如下：Why does Stream<T> not implement Iterable<T>?
奇怪的是，它暗示它以相反的方式去做。

【问题讨论】：

我想这对Lambda Mailing List来说是个好问题。
为什么要遍历流很奇怪？你怎么可能break; 一个迭代？（好吧，Stream.findFirst() 可能是一个解决方案，但可能无法满足所有需求......）
另请参阅Convert Iterable to Stream using Java 8 JDK 了解实际解决方法。

标签： java java-8 java-stream iterable

【解决方案1】：

这不是遗漏； 2013年6月EG名单有详细讨论。

专家组最终讨论植根于this thread。

虽然stream() 在Iterable 上似乎“很明显”（甚至对专家组来说也是如此），但Iterable 如此笼统的事实成为一个问题，因为明显的签名：

Stream<T> stream()

并不总是你想要的。例如，有些东西是Iterable<Integer>，宁愿让他们的流方法返回一个IntStream。但是将stream() 方法放在层次结构中的如此高的位置会使这成为不可能。因此，相反，我们通过提供spliterator() 方法使从Iterable 生成Stream 变得非常容易。 stream()在Collection中的实现就是：

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

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

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

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

【讨论】：

我明白了，首先，非常感谢您回答这个问题。我仍然很好奇为什么Iterable<Integer>（我想你在谈论？）想要返回IntStream。那么可迭代的不是PrimitiveIterator.OfInt吗？或者您可能是指另一个用例？
我觉得奇怪的是，上面的逻辑应该应用于 Iterable（我不能有 stream()，因为有人可能希望它返回 IntStream），而没有给予同等数量的思考向 Collection 添加完全相同的方法（我可能希望我的 Collection 的 stream() 也返回 IntStream。）无论两者都存在还是不存在，人们可能会继续他们的生活，但是因为一个存在而另一个不存在，所以它变得非常明显的遗漏......
Brian McCutchon：这对我来说更有意义。听起来人们只是厌倦了争论并决定谨慎行事。
虽然这是有道理的，但是否有理由没有替代静态 Stream.of(Iterable)，这至少可以通过阅读 API 文档来合理地发现该方法——作为一个从来没有在 StreamSupport 上我什至从未看过 Streams 的内部结构，文档中将其描述为提供“主要用于库编写者”的“低级操作”。跨度>
我完全同意朱尔斯的观点。应添加静态方法 Stream.of(Iteratable iter) 或 Stream.of(Iterator iter)，而不是 StreamSupport.stream(iter.spliterator(), false);

【解决方案2】：

我对几个项目 lambda 邮件列表进行了调查，我想我发现了一些有趣的讨论。

到目前为止，我还没有找到令人满意的解释。看完这一切后，我得出结论，这只是一个遗漏。但是您可以在这里看到，多年来在 API 的设计过程中多次讨论过它。

Lambda Libs 规范专家

我在Lambda Libs Spec Experts mailing list发现了一个关于这个的讨论：

在Iterable/Iterator.stream()Sam Pullara 下说：

我正在与 Brian 一起研究如何限制/子流功能[1] 可能会实现，他建议转换为迭代器是正确的方法。我曾想过解决方案，但没有找到任何明显的方法来获取迭代器并转向它变成一个流。原来它在那里，你只需要先将迭代器转换为拆分器，然后将拆分器转换到一条溪流。所以这让我重新审视我们是否应该拥有这些直接或两者都挂在 Iterable/Iterator 之一上。

我的建议是至少将它放在 Iterator 上，这样你就可以移动在两个世界之间干净利落，也很容易可发现而不是必须做：

Streams.stream(Spliterators.spliteratorUnknownSize(迭代器, Spliterator.ORDERED))

然后Brian Goetz responded：

我认为 Sam 的意思是有很多库类给你一个迭代器，但不要让你一定要自己写分裂器。所以你所能做的就是打电话流（spliteratorUnknownSize（迭代器））。山姆建议我们定义 Iterator.stream() 来为你做这件事。

我想保持 stream() 和 spliterator() 方法不变供图书馆作者/高级用户使用。

And later

“鉴于编写 Spliterator 比编写 Iterator 更容易，我宁愿只写一个 Spliterator 而不是 Iterator （Iterator 是 90 年代 :)"

不过，你没有抓住重点。有数以万计的课程已经给你一个迭代器。他们中的许多人不是拆分器就绪。

Lambda 邮件列表中的先前讨论

这可能不是您正在寻找的答案，但在Project Lambda mailing list 中对此进行了简要讨论。也许这有助于促进对该主题进行更广泛的讨论。

用 Streams from Iterable 下的 Brian Goetz 的话来说：

退一步……

有很多方法可以创建 Stream。您提供的信息越多有关于如何描述元素，更多的功能和流库可以为您提供的性能。以最少的顺序大多数信息，它们是：

迭代器

迭代器 + 大小

分离器

知道其大小的分离器

知道其大小的拆分器，并进一步知道所有子拆分知道它们的大小。

(有些人可能会惊讶地发现我们甚至可以提取并行性在 Q（每个元素的工作量）为不平凡。）

如果 Iterable 有一个 stream() 方法，它只会包装一个 Iterator 一个 Spliterator，没有大小信息。但是，大多数事情是可迭代 do 有大小信息。这意味着我们正在服务流不足。这不太好。

Stephen 在这里概述的 API 实践的一个缺点是接受 Iterable 而不是 Collection，是你在强迫通过“小管道”的东西，因此丢弃大小可能有用的信息。没关系，如果你正在做的一切 to do is forEach it，但如果你想做更多，最好可以保留您想要的所有信息。

Iterable 提供的默认设置确实很糟糕——它即使绝大多数 Iterables 确实知道，也会丢弃大小这些信息。

矛盾？

不过，看起来讨论是基于专家组对最初基于迭代器的 Streams 的初始设计所做的更改。

即便如此，有趣的是，在 Collection 这样的接口中，流方法定义为：

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

这可能与 Iterable 接口中使用的代码完全相同。

所以，这就是为什么我说这个答案可能并不令人满意，但仍然值得讨论。

重构的证据

继续邮件列表中的分析，splitIterator 方法似乎最初是在 Collection 接口中，并在 2013 年的某个时候将其移至 Iterable。

Pull splitIterator up from Collection to Iterable.

结论/理论？

那么很有可能 Iterable 中缺少该方法只是一个遗漏，因为看起来他们应该在将 splitIterator 从 Collection 向上移动到 Iterable 时也移动了流方法。

如果还有其他不明显的原因。其他人有其他理论吗？

【讨论】：

感谢您的回复，但我不同意那里的推理。在您覆盖Iterable 的spliterator() 的那一刻，所有问题都已修复，您可以轻松实现stream() 和parallelStream()..
@skiwi 这就是为什么我说这可能不是答案。我只是想加入讨论，因为很难知道专家组为什么会做出他们所做的决定。我想我们能做的就是尝试在邮件列表中做一些取证，看看我们是否能找到任何理由。
@skiwi 我查看了其他邮件列表，发现了更多的讨论证据，也许还有一些有助于理论化某些诊断的想法。
感谢您的努力，我真的应该学习如何有效地拆分这些邮件列表。如果可以以某种...现代方式将它们可视化会有所帮助，例如论坛或其他方式，因为阅读带有引号的纯文本电子邮件效率不高。

【解决方案3】：

如果您知道可以使用java.util.Collection 的大小，它提供了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();
   }
}

然后：

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

我遇到了同样的问题，我很惊讶我的 Iterable 实现可以通过简单地添加 size() 方法很容易地扩展到 AbstractCollection 实现（幸运的是我有集合的大小:-)

您还应该考虑覆盖Spliterator<E> spliterator()。

【讨论】：