Overload resolution simplification
forax at univ-mlv.fr
Wed Aug 14 04:37:46 PDT 2013
On 08/14/2013 12:11 AM, Ali Ebrahimi wrote:
> 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#.
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
> 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
> 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.)
> - 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.
More information about the lambda-spec-observers