Originally Posted by
schauerlich
It's largely aesthetic reasons; types for functional interfaces are not explicitly functional, the types are less readable, and the call sites do not look the same (func.call(arg1, arg2) vs func(arg1, arg2)).
There are also the aforementioned issues with lexical scoping and variable capture that don't operate like they do in other languages.
This can be handled with syntatic sugar. All of scala's anonymous functions are defined like:
Code:
trait Function6[-T1,-T2,-T3,-T4,-T5,-T6,+R] extends AnyRef {
def apply(t1: T1, t2: T2, t3: T3, t4: T4, t5: T5, t6: T6): R
}
but the type ends up looking like:
Code:
(Int, Float, BigInt, String, Char, Double) => Boolean
because of syntatic sugar. Java sadly doesn't go that far and leaves a lot to be desired with its syntatic sugar for function literals, but with enough there is little to no difference. As for variable capture issues, that can also be sidestepped with functors, though I'm not entirely how scala does it:
Code:
var a = 5
val b = (x: Int) => a += x
b(10) //a now equals 15
Java could probably do all of that without breaking backwards compatibility, but they haven't for some reason. Java 8, last I checked, allowed you to mutate closed over variables if they were class members, not variables local to a function. I don't know if that's still the case or not.
Bookmarks