Syntax for default methods and order of type parameters changes. Both to the worse?

[Simon Ochsenreither]

The default method syntax will change¹ from

public void method() default { foo(); }

to

public default void method() { foo(); }

I haven't found any reasonable rationale for it on the mailing list (or elsewhere).

I wonder why they changed it to be inconsistent with Java's existing default value syntax.

They also changed around the type parameter order to "align better with EG discussions"²:
So basically having a functional interface like Mapper<A,B> will now mean "it maps to A from B" and not "it maps from A to B" anymore.

A reasonable explanation would be that it follows the order of methods definitions. But on the other hand, that would be inconsistent with both the definition of lambdas itself (A -> B) as well inconsistent with the flow of chained operations like list.map(...).filter(...) ...

Ideas/opinions?
Just NIH? Or some evil master plan to ship with requested features, but prevent widespread usage by making them worse than necessary (Optional comes to mind...)? Just joking. :-)

¹ http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006482.html
² http://mail.openjdk.java.net/pipermail/lambda-dev/2012-November/006461.html further discussion in http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-November/000314.html

[Ricky Clarkson]

The rationale was to make default a modifier instead of even more special syntax than it needs to be.

The parameter order isn't very important to me, just a mild irritation that they seem to want to do it the exact opposite way to everything that already exists.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/0TIctYYriksJ.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Simon Ochsenreither]

The rationale was to make default a modifier instead of even more special syntax than it needs to be. 

The reasoning is interesting, even though I disagree that it would cause even more special syntax. The syntax exists since Java 5 already:

String foo() default "";    // default value syntax for annotations
String foo() default {...}; // (old) default method syntax
String default foo() {...}; // (new) default method syntax (!?)

[Ricky Clarkson]

I understand but you must realise that in terms of the actual grammar there would be fewer changes from Java 7 to Java 8 with default as an attribute. I hope IDEA supports this change soon (or already?) so I can continue playing with the benefit of an IDE.

--

You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/XZm8s9CpCbIJ.

[Jess Holle]

I like the default placement.

The Mapper parameter bit just seems inexplicable, though.  Principle of most surprise?

[Simon Ochsenreither]

I'm not sure that this is a reasonable explanation. I don't believe that the designers of one of the most popular language on this planet think that saving the compiler/IDE implementors a few hours¹ is a more important than their actual users, which have to deal with that particular choice for the rest of Java's life.

¹ Compared to the actual changes required for default methods, the idea that they try to save time on the grammar is pretty ... weird. Implementing the grammar addition took me less than 20 minutes, so I don't think that people who deal with this daily will have any issues with it.

[Ricky Clarkson]

Perhaps I think differently to most, but I believe having fewer rules to follow when reading and writing code is better than having more.  It might not make much difference in this case but I think it's a reasonable criterium when adding language features.

Also, bear in mind there is the possibility post-Java 8 of static defenders (final defenders too?), and you might like to be able to see those at a glance instead of having the word 'static' and 'default' separated by the whole method signature.

On Wed, Nov 14, 2012 at 11:13 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

I'm not sure that this is a reasonable explanation. I don't believe that the designers of one of the most popular language on this planet think that saving the compiler/IDE implementors a few hours¹ is a more important than their actual users, which have to deal with that particular choice for the rest of Java's life.

¹ Compared to the actual changes required for default methods, the idea that they try to save time on the grammar is pretty ... weird. Implementing the grammar addition took me less than 20 minutes, so I don't think that people who deal with this daily will have any issues with it.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/LDeCrAVNoWAJ.

[Simon Ochsenreither]

I still fail to see how it would amount to less rules. My disagreement comes exactly from the realization that the inconsistency creates more rules to remember, not less.

[Roland Tepp]

I must admit, the choice of the default value syntax for annotations felt less than intuitive to me when I first saw it.
One can get used to it, but it still feels weird...

New proposal for default method syntax kind of feel better aligned to the most of the language, where all the accessor modifier annotations of a method preceed the type and name of the field/method/type...

[Casper Bang]

On Thursday, November 15, 2012 8:22:40 AM UTC+1, Roland Tepp wrote:

I must admit, the choice of the default value syntax for annotations felt less than intuitive to me when I first saw it.
One can get used to it, but it still feels weird...

New proposal for default method syntax kind of feel better aligned to the most of the language, where all the accessor modifier annotations of a method preceed the type and name of the field/method/type...

Agree with that. The prepended modifier list is a well established pattern, it's the annotation syntax that stands out from the norm.

Java's annotation "default" is clearly not a mere modifier/marker but a somewhat non-orthogonal construct burnt into the compiler front-end, If Java had properties and/or named parameters, this could've been implemented more elegantly on top of existing language constructs instead (the Enum was more successful at doing this, although it suffers from forward-referencing hickups). 

However, Josh Bloch could clearly not copy all of C#'s attributtes given the difference between the two languages. Alas, it seems like the "default" keyword will carry 3 different semantics in Java 8.

[Cédric Beust ♔]

On Thu, Nov 15, 2012 at 1:39 AM, Casper Bang <caspe...@gmail.com> wrote:

However, Josh Bloch could clearly not copy all of C#'s attributtes given the difference between the two languages. Alas, it seems like the "default" keyword will carry 3 different semantics in Java 8.

How so? In all three cases, it specifies a default value (in a switch, in an interface and in an annotation). 

Seems semantically consistent to me. Much more so than, say, final.

-- 

Cédric

[Casper Bang]

On Thursday, November 15, 2012 5:59:16 PM UTC+1, Cédric Beust ♔ wrote:

How so? In all three cases, it specifies a default value (in a switch, in an interface and in an annotation). 

Seems semantically consistent to me. Much more so than, say, final.

 

Just cautious of overloaded context-sensitive keywords, although I agree it's not as bad as final.

[Simon Ochsenreither]

After basically everyone on lambda-dev/lambda-libs-spec-experts tried to tell Goetz to call functions functions, I looked looked into the implementation and I guess, I can understand their concern now:

java.util.function:
-------------------
BiBlock.java
BiFunction.java
BiPredicate.java
BinaryOperator.java
Block.java
Combiner.java
DoubleBinaryOperator.java
DoubleFunction.java
DoubleUnaryOperator.java
FlatMapper.java
Function.java
Functions.java
IntBinaryOperator.java
IntFunction.java
IntSupplier.java
IntUnaryOperator.java
LongBinaryOperator.java
LongFunction.java
LongUnaryOperator.java
Predicate.java
Predicates.java
Supplier.java
UnaryOperator.java

(http://hg.openjdk.java.net/lambda/lambda/jdk/file/ba27872c81f8/src/share/classes/java/util/stream/primitive/)

Not only that the naming seems to be all over the place and hard to remember (yes, names actually matter, read on ...), the manual specialization looks extremely scary. Why are they trying to solve a JVM/JIT problem (assuming Generics will never be improved) in a library in such an arcane and error-prone way (why not use at least M4 macros like in *Buffer)?

Another weird thing is that these specializations are NOT compatible with their more general implementation. So everywhere, where you'd want to define a lambda, a developer now needs to decide if you assign it to e. g. Function<Integer,Integer> or to IntFunction<Integer>. Even worse, there seems to be no right or wrong (as soon as your code is slightly generic on its input, you can't use the specialized functions anymore).

If a developer used the first way and some library uses the second? Bad luck.
If a developer used the second way and some library uses the first? Bad luck, too.

Also scary: http://hg.openjdk.java.net/lambda/lambda/jdk/file/ba27872c81f8/src/share/classes/java/util/stream/primitive/ and (to a lesser amount) http://hg.openjdk.java.net/lambda/lambda/jdk/file/ba27872c81f8/src/share/classes/java/util/stream/op/.

Keep in mind, that classes are currently only specialized to int! So if they keep this approach, the amount of classes in primitive will quadruple (int, long, float, double).

I really hope that Oracle comes up with an better approach, otherwise Java 8 will be the language will give both OOP and FP a bad name ...

[Simon Ochsenreither]

Sorry, the first link should be http://hg.openjdk.java.net/lambda/lambda/jdk/file/ba27872c81f8/src/share/classes/java/util/function/ ...

[Cédric Beust ♔]

This is good feedback, but why are you sending it here instead of lambda-dev?

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/h3N9iR664JgJ.

[Ricky Clarkson]

This is why we all argued for function types, i.e., int -> int doubleTheArgument = x -> x * 2;  Brian thinks this causes a problem with overloading because of erasure, but I don't think that's as big a problem as having to name all these interfaces.  It's relatively easy to avoid overloading.

[Simon Ochsenreither]

Brian thinks this causes a problem with overloading because of erasure, but I don't think that's as big a problem as having to name all these interfaces.  It's relatively easy to avoid overloading.

Amusing, considering that he also wants to name the methods of functional interfaces more inconsistently to make it easier to implement multiple functional interfaces (a requirement which has never arisen (nor posed to be an issue) in those languages which chose consistent names from the beginning), which wouldn't be a problem in the first case if there were a sane, lower-level interface for functions (which would also be great for interop which also multiple people mentioned on the mailing list.)

Looks like they painted themselves into a very unfortunate language design corner by letting their fear of boxing/unboxing costs rule over correctness and simplicity.

[Casper Bang]

On Friday, November 16, 2012 7:06:03 PM UTC+1, Simon Ochsenreither wrote:

Looks like they painted themselves into a very unfortunate language design corner by letting their fear of X costs rule over correctness and simplicity.

At least they are consistent in doing so. :D I know of no other language which carries its warts as proudly as Java.

[mP]

Any idea why bitwise flags are used instead of nice enums ?