Stream constructors for stream(Iterator) in StreamSupport?

[Brian Goetz]

I think Tim's concern is that he recognizes two categories of potential 
users:

  - Library writers who want to expose a stream() method but are not 
ready to take the plunge to Spliterator;
  - Poor users who want a stream and all they can get out of their damn 
library is an Iterator.

The question is, is there a way to not hose the second category without 
making things worse?

On 4/13/2013 5:32 PM, Joe Bowbeer wrote:
> I think the signature fits better in support. (The default method
> alternative negates this.) However another argument is based on the
> expected users. If they are not library writers then it should not go in
> the support class.
>
> On Apr 13, 2013 2:15 PM, "Brian Goetz" <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>         That's a great taxonomy of ways to make a stream, but the
>         division of
>         static factory methods into Streams and StreamSupport wasn't, as I
>         understood it, along those lines. It was about keeping concepts that
>         most users aren't going to want to mess with (i.e., Spliterator)
>         out of
>         their line of sight.
>
>
>     That was indeed part of it.  But the other part of it was guiding
>     them away from low-level tools they might mistakenly (mis)use
>     because we'd not sufficiently labeled things into bins of "for
>     users" and "for library writers."  I still think
>     stream-from-iterator is low-level, because it involves choosing
>     things like stream flags (and doing it wrong will have bad results.)
>
>         If all you have is an Iterator, you don't want have to go down
>         into the
>         basement to get something that turns it into a Stream. Put those
>         tradeoffs on the packaging but leave the package in the kitchen.
>
>
>     So, the tension here is:
>       - helping the poor users for whom all they can get is an Iterator,
>     and they want a stream;
>       - avoiding the moral hazard of encouraging people to think that
>     Iterator is actually a *good* way to make a stream (which might even
>     encourage them to write more Iterators!)  I want them to think is
>     "Iterator is the last possible resort for making a stream, including
>     a number of resorts that I should learn about first before writing
>     an Iterator."
>
>     The current status quo is either better or worse in this, depending
>     on which of the two above forces you are more compelled by.  The way
>     to make a Stream from an iterator currently is:
>
>        Streams.stream(Spliterators.__spliteratorUnknownSize(__iterator,
>     flags));
>        Streams.stream(Spliterators.__spliterator(iterator, size, flags));
>
>     Which do the job but suffer from poor discoverability.  On the other
>     hand, it has none of the moral hazard -- its pretty clear you're
>     nailing bags on bags, and I don't think this status quo is so awful.
>
>
>     Another direction (as discussed previously without convergence)
>     would be to augment Iterable with a stream() method.  This helps
>     users of non-Collection Iterable classes, but still has some of the
>     moral hazard as it does not put enough pressure on writers of
>     Iterable classes to write better stream() implementations.
>