Comments on: A curious fact about overloading in Scala http://www.drmaciver.com/2008/08/a-curious-fact-about-overloading-in-scala/ Wed, 10 Feb 2010 18:19:37 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: david http://www.drmaciver.com/2008/08/a-curious-fact-about-overloading-in-scala/comment-page-1/#comment-422 david Wed, 27 Aug 2008 08:11:51 +0000 http://www.drmaciver.com/?p=219#comment-422 No, I don't think that's the case. It's and covariant return types are the only cases of it actually being used in the Java implementation, but the Java virtual machine spec second edition documents this behaviour and predates both generics and covariant return. No, I don’t think that’s the case.

It’s and covariant return types are the only cases of it actually being used in the Java implementation, but the Java virtual machine spec second edition documents this behaviour and predates both generics and covariant return.

]]> By: Daniel http://www.drmaciver.com/2008/08/a-curious-fact-about-overloading-in-scala/comment-page-1/#comment-421 Daniel Wed, 27 Aug 2008 08:09:01 +0000 http://www.drmaciver.com/?p=219#comment-421 Overloading based on return type was introduced for exactly one reason: When introducing generics with erasure, they needed "bridge methods", and these would often conflict with existing "real" ones. To reduce the number of these clashes, they allowed to use overloading based on return type in the JVM, but not in in the compiler for "normal" code. Overloading based on return type was introduced for exactly one reason: When introducing generics with erasure, they needed “bridge methods”, and these would often conflict with existing “real” ones. To reduce the number of these clashes, they allowed to use overloading based on return type in the JVM, but not in in the compiler for “normal” code.

]]> By: david http://www.drmaciver.com/2008/08/a-curious-fact-about-overloading-in-scala/comment-page-1/#comment-420 david Wed, 27 Aug 2008 07:51:56 +0000 http://www.drmaciver.com/?p=219#comment-420 Indeed. It will confuse the hell out of java.lang.reflect too. Indeed. It will confuse the hell out of java.lang.reflect too.

]]> By: Reinier Zwitserloot http://www.drmaciver.com/2008/08/a-curious-fact-about-overloading-in-scala/comment-page-1/#comment-419 Reinier Zwitserloot Wed, 27 Aug 2008 07:44:00 +0000 http://www.drmaciver.com/?p=219#comment-419 I'm fairly sure most JVM languages, including java, won't understand this. So, cool trick, but can't use it if you need interop with other JVM languages. Which is a bit of a shame, because the whole point of JVM interop is that it's not something you program for or think about, you just get it for free. I'm guessing the original intent was for overloading based on just different return types not to be legal, but then this issue came up, and now its the status quo. I’m fairly sure most JVM languages, including java, won’t understand this. So, cool trick, but can’t use it if you need interop with other JVM languages. Which is a bit of a shame, because the whole point of JVM interop is that it’s not something you program for or think about, you just get it for free.

I’m guessing the original intent was for overloading based on just different return types not to be legal, but then this issue came up, and now its the status quo.

]]>