<div dir="ltr">By the way, my experience with extension methods in Kotlin is not very exciting (hopefully, my colleagues won't hate me on this). Probably it's the tooling problem, but it appears that it's too easy to call the extension method. Like imagine that you have an object myObj of type MyType and want to convert to the OtherType. You type myObj. and check the completion options and happily find that myObj.toOtherType() is suggested, which looks just like something you need. If you are not attentive enough you won't realize that toOtherType() is an extension method that was created in a completely unrelated module in a very specific context to solve a very specific problem, and this method has poor contract and is not applicable generally. Probably, it was declared as public by accident (partially because Kotlin is public-by-default) and was never intended to be used from outside. With a static method, you normally see which class the method belongs to, so such a problem doesn't happen. However, with extension methods, you just have a new entry in the imports list, which is far away from the use-site, so it's hard to notice what you are actually depending on. <div><br></div><div>I made this mistake several times until I disciplined myself to check every time where the method comes from. And I saw such a thing done by other developers as well. Just recently I was working on IntelliJ IDEA project and refactored the JavaDoc inspection UI. I decided to remove a utility class (written in Kotlin and unfortunately public) that was created nearby solely to support the UI of a single inspection. However, our internal plugin compatibility tool yelled at me that there's a third-party plugin in our plugin repository that uses an extension method declared inside of that file. Of course, the plugin has nothing in common with JavaDoc inspection. I suspect that the plugin author just completed something without even checking where it comes from. Now, I need to keep this class and have a deprecation cycle in order not to break the plugin [1].<div><br></div><div>So to summarize, ease of use of extension methods may suddenly become an unpleasant maintenance burden.</div><div><br></div><div>With best regards,</div><div>Tagir Valeev.</div><div><br></div><div>[1] <a href="https://github.com/JetBrains/intellij-community/blob/aa39823b7d3ed082888a749fe3051688be49d2fa/java/java-impl/src/com/intellij/codeInspection/javaDoc/JavadocUIUtil.kt">https://github.com/JetBrains/intellij-community/blob/aa39823b7d3ed082888a749fe3051688be49d2fa/java/java-impl/src/com/intellij/codeInspection/javaDoc/JavadocUIUtil.kt</a></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 28, 2023 at 9:58 PM Tagir Valeev <<a href="mailto:amaembo@gmail.com">amaembo@gmail.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 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)" target="_blank">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" target="_blank">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_8430072893403431327m_-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>
</blockquote></div>