Overload resolution simplification

[Zhong Yu]

On Tue, Aug 13, 2013 at 6:52 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> Hi Ali, do you have more overloading use cases?
>
> Currently I see 3 cases:
>
> 1. primitive vs boxed
>
>     map( T -> Integer )
>     map( T -> int )
>
> 2. flat map
>
>     Future<T>
>         Future<S> then( T -> S );
>         Future<S> then( T -> Future<S> );
>
> 3. void vs Void
>
>         Future<S> then( T -> S ); // where S=Void
>         Future<Void> then( T->void );
>     // in the 2nd version, the lambda body does not need to return (Void)null

Here's another use case. Say someone is doing "async" programming
(which is made practical by the new lambda expression)

    Future<X> doSomethingAsync(){...}

(using some interface like Future/Promise/CompletionStage etc)

An async version of Iterator:

    interface FutureIterator<T>

        Future<T> next();

        <U> FutureIterator<U> map( T->U );
        <U> FutureIterator<U> map( T->Future<U> );

        <U> FutureIterator<U> flatmap( T->FutureIterator<U> );

The 2nd map() method isn't known as flat map; so we'll have to come up
with new name for it if overloading does not work. The same problem
exists for forEach(), fold(), reduce() etc. If overloading does work,
it'll save a lot of trouble for API designer; it's probably easier for
API users; and calling code will look a lot nicer.

If overloading doesn't work here, I don't think programmers would
appreciate that there's a simple explanation why it doesn't work;
they'd rather prefer it works because of some complex reasons.

Zhong Yu