search

szegedi / dynalink

Dynamic Linker Framework for Languages on the JVM
http://szegedi.github.com/dynalink/
BSD 3-Clause "New" or "Revised" License
206 stars 23 forks source link

Support for method resolution including return type #4

Open jozefdransfield opened 12 years ago

jozefdransfield commented 12 years ago

The Java Language does not support method overloading by return type but the JVM specification does. It would be good if this could be supported so that languages or tools that use this feature will continue to work.

JVM Spec 4.3.4 : http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.3.4

"A method signature, defined by the production MethodTypeSignature, encodes the (possibly parameterized) types of the method's formal arguments and of the exceptions it has declared in its throws clause, its (possibly parameterized) return type, and any formal type parameters in the method declaration."

Example: see Proguard http://proguard.sourceforge.net/index.html#manual/usage.html (overloadaggressively)

"Counter-indication: the resulting class files fall within the Java bytecode specification (cfr. The Java Virtual Machine Specification, Second Edition, first paragraphs of Section 4.5 and Section 4.6), even though this kind of overloading is not allowed in the Java language (cfr. The Java Language Specification, Second Edition, Section 8.3 and Section 8.4.7). "

szegedi commented 12 years ago

I will look into this. It might be worthwhile to take into account when selecting the overloads. As you noted, since it isn't part of the JLS spec, there's no prescribed JLS semantics for use of this information in overloaded method resolution. I'm leaning towards only using it when there's several candidates that only differ in the return type, although if you have some other semantics in mind, please let me know.