tee()

[Martijn Verburg]

Hi all,

We were discussing this from the IDE implementors perspective as well.
 They certainly would want to be able to hook in between the lazy
operations when asked to debug.  Putting on my pure developers hat I'd
be OK with that being a development time only thing, the IDE could
even weave in the equivalent of a peek() call. Putting on my realists
"Oh crap I need to see what's going on in Live" hat I certainly see
Kevin's point..

I'll leave it to the experts as to whether that's feasible or not
though, I suspect I'd think this through in a somewhat naive manner
:-).

On 24 January 2013 21:10, Kevin Bourrillion <kevinb at google.com> wrote:
> Okay, what I'm about to suggest may be ridiculous; I don't know.
>
> But when I want to debug, I want to debug without having to make a code
> change!  I even want to debug straight in production.  So what I would wish
> that I could do is attach my debugger, <handwave> flip some system property
> or static boolean somewhere, and that causes all stream operations to be
> executed eagerly as they are specified.  Now I can break anywhere I want
> and see what I want to see.
>
>
> On Thu, Jan 24, 2013 at 1:05 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> 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>
>>>
>>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com