Overload resolution simplification

[Zhong Yu]

On Thu, Aug 15, 2013 at 8:49 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> 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.


Another possible use case, involving legacy interfaces. Say I have

    /** return a list of error strings */
    static <T> List<String> validate(List<T> args, Validator<T> validator){...}

    interface Validator<T>
        void validate(T arg) throws ValidationException<T>

Now suppose there's a legacy 3rd party validator interface that does
roughly the same thing, and my API needs to support it. It's semantics
and signature are a little different

    interface Checker<T>
        CheckResult<T> check(T arg)

hopefully I can overload validate() to accept and handle it

    static <T> List<String> validate(List<T> args, Checker<T> checker){...}

If there is another legacy interface whose signature is similar to mine

    interface Examiner<T>
        void examine(T arg) throws ValidationException<T>

I'm in trouble because the return type of a lambda expression isn't
enough to disambiguate. However if a subtype relationship can be added
between Validator and Examiner (in either direction), overload could
still work because one method is more specific than the other.


Zhong Yu