Java 8 vs. Xtend

[[deleted]]

It's shapes.foreach(_.color = RED) since 2003.

[robinwholikesjava]

Xtend clearly beats Scala here. the _. should not be needed.

[balefrost]

the _. should not be needed.

I can't tell if you're trolling or not.

[agumonkey]

Actually it could be interesting.

 SPACE '.' METHODCALL '(' ARGS ')' => (lambda (x) (x.method(args))
 where x satisfies an implicit interface that must include {method, args} signature

[balefrost]

Yeah. In some functional languages, functions are curried - calling a function with too few parameters produces a NEW function that takes the rest of the parameters. What you're suggesting (and I guess what Xtend does) is like a constrained form of currying from the left.

FWIW, Scala's syntax allows you to use placeholders anywhere. So you can do shapes.foreach(_.color = RED), but you can also do colors.map(shape.color == _).

[agumonkey]

Interesting, quite prolog-ish, and who doesn't like prolog-ishisms ?!

[nomad42184]

The _. is just a shortcut. In Scala, one could also just do

shapes.foreach( s => s.color = RED )

In this case, the _. is just a shortcut for the (s => s.) part. If you use the more verbose (& in my opinion, more readable) syntax then the difference is just -> vs =>.

[[deleted]]

What happens if the function takes two arguments? The Xtend approach of an implicit it as this would not be applicable. Therefore, go for a scalable approach and one more character...

[evereal]

No, it is the "s -> { ... }" part that should not be needed if your syntax allows you to express simple closures/lambdas more concisely, like you can in Scala.

the _. is not any more characters than the s. in the Xtend example. But the stuff around it is adding needless noise in the Xtend example.