Loose end: concat

Sam Pullara spullara at gmail.com
Thu May 23 11:23:49 PDT 2013


*Stream seems like the right place for them to me. It is certainly the second place I would look — first place would be as an instance method, but we've discussed that before.

Sam

On May 23, 2013, at 11:06 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I cleaned up concat() and wrote Int/Long/Double versions.  (Fortunately, with the recent addition of Spliterator.OfPrimitive, the duplication quotient was much lower.)
> 
> Currently these still live in Streams.  Is that still the right place? The stream classes (Stream, IntStream, etc) seem a little wrong for them, but I can't quite put my finger on why.
> 
> Specs:
> 
>    /**
>     * Creates a lazy concatenated {@code Stream} whose elements are all the
>     * elements of a first {@code Stream} succeeded by all the elements of the
>     * second {@code Stream}. The resulting stream is ordered if both
>     * of the input streams are ordered, and parallel if either of the input
>     * streams is parallel.
>     *
>     * @param <T> The type of stream elements
>     * @param a the first stream
>     * @param b the second stream to concatenate on to end of the first
>     *        stream
>     * @return the concatenation of the two input streams
>     */
>    public static <T> Stream<T> concat(Stream<? extends T> a, Stream<? extends T> b) {
> 
> 
>    /**
>     * Creates a lazy concatenated {@code IntStream} whose elements are all the
>     * elements of a first {@code IntStream} succeeded by all the elements of the
>     * second {@code IntStream}. The resulting stream is ordered if both
>     * of the input streams are ordered, and parallel if either of the input
>     * streams is parallel.
>     *
>     * @param a the first stream
>     * @param b the second stream to concatenate on to end of the first stream
>     * @return the concatenation of the two streams
>     */
>    public static IntStream concat(IntStream a, IntStream b) {
> 
> 
> (and similar for Long and Double).
> 



More information about the lambda-libs-spec-observers mailing list