This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Overloading of methods that take Functional interfaces as parameters.  RSS feed

 
Chan Ag
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Isn't overloading of methods that take Functional interfaces as parameters a risky thing. What if the classes, in which these overloaded methods are present, coded much before such interfaces are actually created.

Consider this.



Most of the code in the above class is from http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/java/javaOO/examples/Person.java ( This is copied as is-- so why the createRoster() method is in Person class and other such questions - let us ignore them for now).

Now as we see, I have two overloaded methods with the name performAction2. The only difference is one of them takes a Predicate

parameter and the other one takes Predicate2

parameter. The compiler allows this.

I created Predicate2<T>by copying the source code of Predicate<T> and changing all references of Predicate to Predicate2.

Now I can't use Lambda expressions to call them.
If I call them as follows using Lambda expression syntax,



I get the following compilation error.

The method performAction2(List<Person>, Predicate<Person>, Function<Person,Object>, Consumer<Object>) is ambiguous for the type Person.


Shouldn't the Lambda expression syntax have been different? I mean why should lambda expressions syntax have no way of specifying which interface is being implemented? What do you think?
 
Chan Ag
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, This must be ok cause we can use the anonymous classes or local classes or just implementing classes type syntax to invoke these methods.

We should have no reason to duplicate such functional interfaces ( they are interfaces after all ) and if we at all have to create a similar interface for some weird reason, then we can't use lambda expressions to invoke such overloaded methods. It's not like those methods are going to become useless. We can still use implementing classes and the old, evergreen syntax.

I guess I posted this question too early.
 
Rob Spoor
Sheriff
Posts: 21088
85
Chrome Eclipse IDE Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can use a reference instead:
 
Chan Ag
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Awesome. Thanks, Rob.

I should have tried this. But this didn't even strike me.


 
Rob Spoor
Sheriff
Posts: 21088
85
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're welcome.
 
Scott Shipp
Ranch Hand
Posts: 223
12
Eclipse IDE IntelliJ IDE Java Scala Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Chan Ag wrote:
We should have no reason to duplicate such functional interfaces ( they are interfaces after all ) and if we at all have to create a similar interface for some weird reason, then we can't use lambda expressions to invoke such overloaded methods. It's not like those methods are going to become useless. We can still use implementing classes and the old, evergreen syntax.


Hi Chan...I don't know if I am reading you right here. But I wanted to mention that you can create your own interfaces and invoke them with lambda expressions. Example here, I've created the "Generator" interface in lines 1-3, I pass it as the fourth parameter in the "generateSeries" method on line 5, and down in line 24 I pass a Lambda expression into it:

 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!