On Mon, 16 Aug 2021 03:39:02 GMT, Tagir F. Valeev <tval...@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. It is fine that the pull request is closed for now, but I agree with @amaembo that if this conversation is indeed mirrored there, then it shouldn't be a problem to discuss the proposal here, along with the proposed changes. I actually worked out a usecase (See: https://github.com/CC007/InterfaceSegregationDemo), where I partially reimagined the Collection interface stack and its neighboring interfaces/classes. I also added a `Demo` class to show how I imagined to use these interfaces and to show how the granularity of these interfaces can be useful. The fact that I have to create copies of interfaces and delegates for implementations makes me feel like something is lacking in the collection stack and that for this usecase `Supplier<E>` wouldn't cut it, but feel free to fork and refactor my code to prove me wrong. PS: while creating the Demo class, I noticed that it couldn't be analyzed if the return value of a method with type `<T extends Streamable<String> & Addable<String> & Iterable<String> & RandomAccess>` could be safely cast to a new local variable with type `<SA extends Streamable<String> & Addable<String>` and that you can't declare variables of type `<? extends Streamable<String> & Addable<String>` (it won't let you use the `&` when using the `?`), but I digress. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050
