Kev*_*inO 16 java java-8 java-stream
为了防止实现细节泄漏,而不是返回,例如,Collection<MyCoolObject>可以实现Iterable<MyCoolObject>,然后需要Iterator<T>从Iterable接口实现.因此,无论如何管理内部数据结构,对元素的访问都是通过Iterator.
使用Java 8,可能希望添加Stream<MyCoolObject> stream()到MyCoolObject.(另请参阅:Java 8 Lambdasstream一书中支持的建议).虽然添加方法并不困难(我确实阅读了关于为什么Iterable不提供流的问题),但Java似乎没有添加一个接口来反映这个想法.(好吧,可能因为使用CORBA的东西而存在一个不同的名称).Streamable<T>Iterable<T>Streamable
我想,我也跟着为什么加入应答Stream到Iterable了可能存在问题,但我不明白为什么一个Streaming<T>已经不能提供的接口.例如,Collections可以实现Streaming<T>接口,并且可以使人们可以期待stream()方法的其他对象更清楚.
基于对上述引用问题的答案,可以Stream从Iterable通过获得
Stream s = StreamSupport.stream(iter.spliterator(), false);
但这看起来似乎很多工作,MyObject可能只想实现stream()允许对象的用户这样做
myObject.stream().filter(...).collect(...)
没有来自迭代器的干预转换.
缺少流媒体功能对象的接口是否有原因？有没有比仅仅stream()在MyCoolObject上实现并让某人查看Javadoc以便他们知道它有stream()方法更好的方法？
或者,很可能,我是否误解了Stream的方法？
(另外,我stream()在CoolObject中实现,但后来忘记实现parallelStream(),这可以通过使用接口来缓解).
Eug*_*ene 11
这可能会增加任何未来的答案.
我不知道为什么你认为返回Iterable<MyCoolObject>而不是Collection<MyCoolObject>更好.它可能确实隐藏了细节,并且还会产生更多问题.
集合known size在分割并行处理时起着重要作用.这被报道为Spliterator.SIZED | Spliterator.SUBSIZED.所以a Collection.stream会比a更好地处理并行流Iterable,它将使用:
public static <T> Spliterator<T> spliteratorUnknownSize
记录为:
...并实现trySplit以允许有限的并行性.
这很明显,因为你根本不知道它的大小.在当前实现下,批量大小是1024.因此,例如,对于1024个元素以下的任何内容,您根本不会获得任何并行化.
现在,就你的问题而言,在jdk-8的早期版本中曾经有过这样的事情.它被称为java.util.stream.Streamable.从我所知道它被删除,因为有方法返回a Stream,但不是通过stream()方法.
String::codePoints()
File::lines
Pattern::splitAsStream
... many others
因此,实现此功能的唯一地方是收藏.而据我所知,这将是一个非常孤立的地方.
啊啊时刻
以下是负责人的解释.
正如这里建议的那样是删除原因:
我正在考虑放弃Streamable接口.目前唯一的实现者是Collection,并且所有其他流方法都提供专用流(chars(),codePoints(),lines()等),其方法名称比"stream"更合适.所以我认为我们应该删除Streamable并将stream()/ parallel()方法保留在Collection上(或者可能将它们向上移动Iterable).