Overload resolution simplification

Zhong Yu zhong.j.yu at gmail.com
Thu Aug 15 17:43:35 PDT 2013

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

More information about the lambda-spec-observers mailing list