tee() (original) (raw)

Brian Goetz brian.goetz at oracle.com
Thu Jan 24 13:05:45 PST 2013

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 gets returned from API X and passed into API Y and people don't realize it; that lazy evaluation happens god-knows-when. Stream 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>

More information about the lambda-libs-spec-observers mailing list