On Mon, 9 Aug 2021 12:28:23 GMT, CC007 <github.com+5381337+cc...@openjdk.org> 
wrote:

> create Streamable and ParallelStreamable interface and use them in Collection 
> and Optional

Mostly agreed with Brian. Judging from 7 years of using Stream API, I can say 
that this abstraction would not solve any real problem. If you need a way to 
create many identical streams on demand, just accept `Supplier<Stream<T>>`. 
This allows more flexibility for clients. They can not only supply 
`myCollection::stream` or `myOptional::stream` but also `() -> 
Arrays.stream(myArray)`, `() -> IntStream.range(...).boxed()`, `() -> 
myCollection.stream().filter(something)` or whatever else. A dedicated 
`Streamable` interface is too limited and will require adapters in many cases 
but you can already adapt anything to `Supplier<Stream<T>>`. People already use 
`Supplier<Stream<T>>` idiom pretty often, so creating a new `Streamable` 
interface would add an API mess: some people would stick with `Supplier` and 
others would migrate to `Streamable`. So I vote to reject this PR.

I said "mostly" because I think that PR is a good starting point for 
discussion. It's much easier to explain which enhancement you are proposing if 
you already present some code. And we are already at corelibs-dev, as PR 
comments are mirrored there, and for some people, it's more comfortable to 
discuss via GitHub interface, as you don't have to subscribe and get tons of 
unrelated e-mails, you can concentrate on a single discussion only. So in my 
opinion, it's completely ok to write code and create a PR before the 
discussion, even if it's likely to be thrown away.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5050

Reply via email to