Stream constructors for stream(Iterator) in StreamSupport?

[Jim Mayer]

Hi Brian,

How about introducing a new method name, like "adapt",  "asStream", or
"convert" that implies overhead?

Another possibility would be to introduce a new class, like
"StreamConverters" whose name, again, implies the additional overhead.

Jim


On Sat, Apr 13, 2013 at 6:02 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

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