tee()

[Brian Goetz]

But streams *are* lazy.  What confuses people is that when you say:

   stream.filter(...)
         .map(...)
         .reduce(...)

the filtering, mapping, and reducing are all happening *at once*.  Users 
will look for a place to stick a breakpoint "after the filtering" and 
come up empty.  By putting a "peek()" call with debugging code, now they 
have a place to put a breakpoint or print stuff out, so they can debug 
complex pipelines stage by stage.

On 1/24/2013 4:02 PM, Kevin Bourrillion wrote:
> On Thu, Jan 24, 2013 at 12:53 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Don convinced me of the need for this one when he described
>     experiences his team had adapting to lazy collections in their
>     libraries.
>
>
> Depending on the details of that conversation, I either buy it or don't
> buy it. :-)
>
> Lazy collections are a whole other story; Collection<E> gets returned
> from API X and passed into API Y and people don't realize it; that lazy
> evaluation happens god-knows-when.  Stream<E> makes that a lot better.
>
>
>
>     On 1/24/2013 3:43 PM, Kevin Bourrillion wrote:
>
>         tee() stands out like a sore thumb.  I'm not surprised that
>         Brian says
>         "this method is mostly for debugging."
>
>         It just feels very, very strange to let the user inject a
>         side-effect
>         into the middle of their stream somewhere, for mysterious hidden
>         later
>         execution /maybe/.
>
>
>         If it really must stay, I think I do like "peek" or "observe" over
>         "tee". But I would love to drop it.
>
>         --
>         Kevin Bourrillion | Java Librarian | Google, Inc.
>         |kevinb at google.com <mailto:kevinb at google.com>
>         <mailto:kevinb at google.com <mailto:kevinb at google.com>>
>
>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
> <mailto:kevinb at google.com>