Java has always supported static dispatch looking like dynamic dispatch.. instance.staticMethod(args), it's just deemed poor form. I don't think erasure has any bearing on method resolution.
Are you a fan of Scala's implicit conversions? Those make it so that foo.bar(baz) can really be someConversionMethod(foo).bar(baz), actually harder to predict than extension methods. Similarly, Scala's approach doesn't show up in reflection as far as I know (at least in Java reflection; I haven't looked at the Scala reflection library yet). It's probably best that extension methods a la C# don't appear in reflection, because they're a static construct and you could genuinely have two separate implementations of the same method used in separate parts of code. You wouldn't want any potential for runtime conflicts caused by a static convenience. On Mon, Oct 29, 2012 at 11:35 AM, Simon Ochsenreither <simon.ochsenreit...@gmail.com> wrote: > 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 javaposse@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
