Overload resolution simplification

[Remi Forax]

On 08/14/2013 12:11 AM, Ali Ebrahimi 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

Hi Ali,
the interropt problem is when you have an API with at least two 
overloads that are SAMs,
this is not as common as you may think (and as I have though myself not 
so long ago :)
Do you have concrete example of already existing API to exhibit such 
behaviour ?

Rémi

>
>
> On Sun, Aug 11, 2013 at 11:55 PM, Brian Goetz <brian.goetz at oracle.com 
> <mailto: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.
>
>