SelectMany or other useful operators from Rx (Ix)

Paul Sandoz paul.sandoz at oracle.com
Wed Jan 9 06:03:28 PST 2013


On Jan 9, 2013, at 2:32 PM, Dávid Karnok <akarnokd at gmail.com> wrote:

> Hello,
> 
> My apologies if this was asked before.
> 
> You might be aware of the recently open-sourced Reactive and Interactive
> Extensions C# library, which features many of the operators of the new Java
> 8 Stream API (under different naming).
> 
> Is it worth taking a few operator ideas from this library?
> 
> For example, the SelectMany operator, which takes a stream of Ts, and for
> each T, a new stream of Us is produced, and at the end, these U streams are
> flattened into a single stream of Us:
> 
> Stream<U> selectMany(Stream<T>, Function<T, Stream<U>>);

See:

  <R> Stream<R> mapMulti(MultiFunction<? super T, R> mapper);

public interface MultiFunction<T,U> {
    public void apply(Collector<U> collector, T element);

    /** A collector for values associated with a given input.  Values can be
     * yielded individually, or in aggregates such as collections, arrays, or
     * streams; aggregates are flattened, so that yielding an array containing
     * [1, 2] is equivalent to yield(1); yield(2).
     */
    public interface Collector<U> {
        void yield(U element);

        default void yield(Collection<U> collection) {
            for (U u : collection)
                yield(u);
        }

        default void yield(U[] array) {
            for (U u : array)
                yield(u);
        }

        default void yield(Stream<U> stream) {
            stream.forEach(this::yield);
        }
    }
}

Paul.


> 
> I'm asking these because how default interface methods was chosen over C#
> style extension methods, where in the latter case I would just write a
> library for the operators and enjoy the dot-into simplicity. The former
> case leaves me (us) ask the owner of the particular interface for new
> default methods hopefully delivered in the next version, or stick with the
> static method call or wrapper-class approaches.
> 
> Best regards,
> David Karnok
> 




More information about the lambda-dev mailing list