Stream constructors for stream(Iterator) in StreamSupport?

[Joe Bowbeer]

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> 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.
>
>