<div dir="ltr"><div dir="ltr">>
<span style="font-family:monospace;font-size:large">The second example -- changing how parallel execution works -- requires reinventing almost all of the implementation of Streams (which, if you've never looked at it, is a lot more complicated than you might think.) In which case the surface expression here is the least of your problems. </span><br></div><div dir="ltr"><div><span style="font-family:monospace;font-size:large"><br></span></div><div><font face="monospace" size="4">Sorry for moving the discussion away but I cannot stay aside when there's Stream API on the table :-) Implementing .parallel(fjp) (fjp, not just any executor) is not that hard as it seems. The only thing you need is to create a tiny wrapper delegate over the original stream that remembers the supplied fjp, and then submit every terminal operation to that fjp and join the result. I implemented this in my StreamEx library [1], and this one is definitely not the hardest Stream API extension that I implemented.</font></div><div><font face="monospace" size="4"><br></font></div><div><font face="monospace" size="4">That said, as you need to wrap Stream API anyway, you can make it quite comfortable without extension methods. You need to create a bunch of factories repeating stream sources from JDK, like StreamEx.of(Collection) instead of Collection.stream(). Not so huge work either. And then you can add .toSet() :-)</font></div></div><div><br></div><div>With best regards,</div><div>Tagir Valeev.</div><div><br></div><div>[1] <a href="https://www.javadoc.io/static/one.util/streamex/0.8.1/one.util.streamex/one/util/streamex/AbstractStreamEx.html#parallel(java.util.concurrent.ForkJoinPool)">https://www.javadoc.io/static/one.util/streamex/0.8.1/one.util.streamex/one/util/streamex/AbstractStreamEx.html#parallel(java.util.concurrent.ForkJoinPool)</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 28, 2023 at 9:11 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<font size="4"><font face="monospace">Not to pick on your example,
but I'm going to pick on your example....<br>
<br>
You give as examples two methods you'd like to add to Stream:
toSet and parallel(Executor) -- and it is notable that these
examples are fairly commonly cited when this topic comes up.
Note that the first is entirely a cosmetic thing; we already
have collect(Collectors::toSet), so all this does is save a few
characters -- its just code golf. <br>
<br>
The second example -- changing how parallel execution works --
requires reinventing almost all of the implementation of Streams
(which, if you've never looked at it, is a lot more complicated
than you might think.) In which case the surface expression
here is the least of your problems. <br>
<br>
Now, it's easy for someone to complain "why didn't they make
streams extensible" (we actually spent a lot of time exploring
how this might work), but the reality is, Streams does not
actually let users plug in new operations except through defined
extension points like collect(), regardless of how easy or hard
the language would make that. And the tricks that would create
the illusion of doing so, like extension methods, force you to
give up a significant portion of the nonfunctional value of
streams, because a static "extension" method can't fuse
operations, can't access the parallel machinery used by the rest
of streams, can't interact with short-circuiting easily, can't
take advantage of in-place optimizations, etc. So making a
"static" extension look like a built-in method with chaining
actually obfuscates what is going on, depriving readers of cues
about the runtime behavior. <br>
<br>
Returning to your question, the problem of "wrapping streams" is
one of the streams framework having a significant amount of
complexity under the hood, which makes "tapping into it" hard --
and that's the real problem. And -- and here's the kicker --
this complexity shows up in most APIs that are candidates for
heavy use of chaining anyway. <br>
<br>
<br>
<br>
<br>
</font></font><br>
<div>On 3/28/2023 2:51 PM, Archie Cobbs
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Tue, Mar 28, 2023 at 10:48 AM Ron Pressler
<<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>>
wrote:</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As usual, the main
challenge is understanding what exactly is the problem here
— is this a specific issue with CF and Stream or something
more general — and if there is a general problem, what
exactly is it, and does it justify a change to the language.
Only after we answer that can we consider adding a language
feature.<br>
</blockquote>
<div><br>
</div>
Great point - which also makes me curious how we should define
the underlying problem here.<br clear="all">
</div>
<div><br>
</div>
<div>One problem is "prettier chaining" which as Brian pointed
out makes for a relatively weak case.</div>
<div><br>
</div>
<div>What about another problem, which is that in Java it's too
hard to "wrap" something with new functionality? I.e., this is
the same problem extensions try to solve.<br>
</div>
<div><br>
</div>
<div>Just to be clear, suppose I invent this (using Kristofer's
example):</div>
<div><br>
</div>
<div style="margin-left:40px"><span style="font-family:monospace">public interface
BetterStream<T> extends Stream<T> {</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"> BetterStream<T>
parallel(Executor e)<br>
Set<T> toSet()</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"> <a class="gmail_plusreply" id="m_-7179041101689739689plusReplyChip-3">@Override</a><br>
</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"> BetterStream<T>
filter(Predicate<? super T> pred) // etc.<br>
</span></div>
<div style="margin-left:40px"><span style="font-family:monospace">}<br>
</span></div>
<div><br>
</div>
<div>It's not easy to wrap Streams I encounter to convert them
into BetterStreams. I agree with Brian that "API designers
should control their API's" so I suppose we're talking about a
true "wrap", not a "monkey patch". You can do a "wrap" today
but it's tedious and brittle. Could the language make it
easier somehow?<br>
</div>
<div><br>
</div>
<div>I'm sure this has been discussed before. Curious what's the
current status of that discussion.<br>
</div>
<div><br>
</div>
<div>-Archie</div>
<div><br>
</div>
<span>-- </span><br>
<div dir="ltr">Archie L. Cobbs<br>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>