Overload resolution simplification

[Zhong Yu]

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

It'll be a pity if we need to add some fluff to a method name, not for
semantics reasons, but to overcome language deficiencies.

Zhong Yu


On Tue, Aug 13, 2013 at 5:11 PM, Ali Ebrahimi
<ali.ebrahimi1781 at gmail.com> wrote:
> Hi,
> I don't Agree.
> Java popularity is mostly as for its legacy third party code base. And one
> of main goals of java lambdas was its interoperability with legacy code
> (through SAM conversion).
> One note you should consider in decisions is that you should not make
> decisions only based on Streams framework implementation requirements. Many
> of peoples may be even not use Streams framework because of its verbosity.
> Even we will see more fluent APIs on top it.
> So only supporting Streams framework should not be goal for an feature of
> java language.
>
> C# is most similar language to java. C# supports Overloading and type
> inference among many other things. So why java can not support them. May be
> we need learn from C#.
>
>
> Ali
>
>
> On Sun, Aug 11, 2013 at 11:55 PM, Brian Goetz <brian.goetz at oracle.com>wrote:
>
>> What makes you think the goal is encouraging explicit lambdas?
>>>>
>>>
>>> Overloads are part of the java legacy. Ignoring them and you will see
>>> enterprise guidelines saying that only explicit lambdas should be used.
>>> Otherwise, it will break when someone will add an overload.
>>>
>>
>> Overloads are part of the legacy, but the number of genuine SAM-SAM
>> conflicts with existing APIs are pretty small -- I think Executor.submit()
>> is the #1 case, and there are only a handful of others.
>>
>> What we're trying to discourage is new, designed-for-lambdas APIs from
>> getting out of hand with overloads.  Overloading and type inference work
>> against each other, so if you want to design an API for type inference, you
>> need to dial back on the overloading.  (Which we've gradually done
>> throughout the course of designing the java.util.stream API, for a host of
>> reasons.)
>>
>> So:
>>  - For new APIs, go easier on the overloading when there are possible SAM
>> conflicts;
>>  - For old APIs that have such conflicts, go explicit.
>>
>> Maurizio's latest patch also includes a lint warning for overloads that
>> are asking for trouble, so hopefully API designers will have a way of
>> catching those early.
>>
>>