Hi Ricky, Java has always supported static dispatch looking like dynamic > dispatch.. instance.staticMethod(args), it's just deemed poor form.
Of course. I just try to forget that as much as possible. :-) I don't think there is any recent IDE which doesn't yell at you if you try to use this syntax. So I think it is safe to say that generally, a developer can expect that stuff which looks like dynamic dispatch is dynamic dispatch these days in Java. > I don't think erasure has any bearing on method resolution. > http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12 http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.4.3 These two things are by far the most complicated parts of the whole specs. It is almost completely impossible to figure out what is actually allowed and what not without writing positive/negative test-cases for every single line of the spec. I guess that's the reason why even the official implementation from Oracle/openJDK violates the spec. (See the IKVM blog.) > 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. > A "fan" would be a bit too much. Until now, they are the just the least bad approach I have seen. The dispatch on bar is still dynamic btw (but that's only nitpicking, because the conversion is computed by the static type of foo). I share your concern here. One thing which makes the issue less pronounced than in other languages is that the combination of - a deprecation policy which actually removes things - traits - more classes are final tends to eliminate a lot of those situations where one would want to use extension methods. Imo implicits have a better cost/benefit ratio than extension methods, because it is a more general concept which fits into the general notion of OOP instead of some ad-hoc mechanism. The notion of "we add methods, not because it's fun, but to implement interfaces" is probably a good example. Additionally, they allow library implementations of many things which would otherwise be hard-coded in the language/compiler, like implicit conversions. Considering the huge amount of implicit conversion in Java, I'm pretty happy that many of those necessary for compatibility are implemented as simple methods in Scala, allowing developers to use their IDE to find them. If for instance Java would drop their pretty insane implicit widening conversions, the appropriate implicit methods could just be removed from the standard library in Scala. (implicit widening conversions are actually a pretty bad example, because they have a lot of subtle impact on method resolution, subtyping, etc. which is pretty faithfully supported in Scala, so it would be a bit more work in this case.) As a conclusion, a lot of those things normally addressed by extension methods are solved using more standard means in Scala and implicits are a more general mechanism covering issues extension methods can't solve (and which are normally addressed with a lot of more ugly and complicated means). 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). I think there is some method for runtime reflection (or did I confuse something?). If you use compile-time reflection, you get them via the Context argument, as far as I remember. > 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. > Yes! That's exactly what I meant with it "would require capturing the whole environment of the method call to figure out if an eligible extension method is in scope". 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/-/LItriyeZT88J. 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.
