Overload resolution simplification

[Ali Ebrahimi]

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.
>
>