Personally, I think Java's approach is superior to extension methods, because it ensures that dynamic dispatch looks like dynamic dispatch. Allowing both static dispatch (via extension methods) and dynamic dispatch (via standard method call) for the same syntactical representation is confusing for readers and adds complexity to the already too complex topic of method resolution (boxing, erasure, etc.).¹
In my opinion, foo.bar(baz) should always invoke a method on type Foo, not "the compiler figures out whether Foo has such a method and if not rewrites it to some static invocation of an extension method in scope FooExtension.bar(foo, baz)". Additionally, reflection "just works" with default methods whereas supporting extension methods in reflection (I'm not sure whether C# for instance doesn't support it at all.) would require capturing the whole environment of the method call to figure out if an eligible extension method is in scope. The only thing which I don't understand is why they decided to call it "extension methods". It is misleading because Java's "extension methods" lack two properties more or less universally accepted: static dispatch, allowing extension of foreign code. Imho, both "default methods" and "defender methods" are better names, but I guess Oracle's marketing objected ... In the end, I can understand Oracle's decision for implementing default methods this way. They are both technically superior to extension methods and uphold their (and Sun's) rule of "users of our language are not allowed to modify or extend library classes in any way". If there is still a community that cares, they should speak up. > Some prominent members are not even grasping the concept behind it yet, so this sounds hard considering the limited amount of time remaining. ¹ I have only read the specification of the new method resolution/invocation rules, not tested it yet. Defender methods add another lookup step to the end, but I'm not sure whether it creates any new corner cases for the users. The usual stuff will work as expected of course, but it will be interesting to see how the JVM will behave when methods will be added or removed, made private, will get/lose default implementations, etc. This has already been a complicated topic, were the JVM changed behavior randomly and backward-incompatibly (it actually got worse in Java 7). If I can trust what people who know more than me on that topic say, it seems that both Java 6 and Java 7 are violating the VM spec concerning method resolution. Let's hope the situation improves for Java 8. Bye, Simon -- 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/-/9Zezv6mmMFIJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
