<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <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 class="moz-cite-prefix">On 3/28/2023 2:51 PM, Archie Cobbs
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CANSoFxsxFBS0n5BSY4gypDLptCNF7OAqZZ8q3itn9U54xNteWA@mail.gmail.com">
      
      <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" moz-do-not-send="true" class="moz-txt-link-freetext">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="plusReplyChip-3" moz-do-not-send="true">@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>
  </body>
</html>