Make BaseStream public?

[Brian Goetz]

Paul and I groveled through old notes and came to the conclusion that 
the reasons BaseStream was not public earlier had to do with bad 
interactions (limits of generics) with abstractions that no longer 
exist, including StreamShape and MapStream.  So the proximate reasons we 
originally made it nonpublic have gone away.

BaseStream currently holds the following methods:

   iterator/spliterator
   sequential/parallel/isParallel
   unordered
   close/onClose

We could (not saying we should) consider adding the following methods 
common to all Stream types, which if you squint a bit might fit in this 
club:

   limit/substream
   count



On 7/2/2013 4:42 AM, Paul Sandoz wrote:
>
> On Jul 1, 2013, at 10:39 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:
>
>> I am currently crawling through the docs getting ready for another pass on the specification.  The good news is that the class hierarchy has simplified a lot since the first pass.  The bad news is I am trying to tack a course between the twin evils of duplicated documentation and excessive linking (each level of linking loses some percentage of the readers.)
>>
>> The classes Stream, IntStream, LongStream, and DoubleStream all implement BaseStream, which describes behaviors common to all streams (closeability, iterator/spliterator, sequential/parallel, ordering). Currently BaseStream is package-private, but I am thinking that it might be valuable to elevate it to public, for possibly two reasons:
>>
>> - Having a common supertype allows library code to abstract over all stream types.  Our tests use this ability, for example.
>>
>> - Most of the documentation for the stream classes (sequential and parallel behavior, ordering, etc) is generic to all stream types, so putting it in one base class (where it can be @inheritDoc'ed or linked) is more natural than cutting and pasting it in N places, or dumping it all in the package doc.
>>
>
> +1
>
> If/when there is an SPI there could be value in making a test framework available publicly as well without resorting to boot classpath tricks.
>
> I am struggling to recall why we did not do that earlier. At one point we had some methods/types on BaseStream we did not want to expose publicly, but they all withered away as the implementation got simpler.
>
> Paul.
>