method overloading for classes/interfaces marked 'native("jvm")'

The Ceylon typechecker and Java backend have supported method overloading for rather a long time, since Ceylon code needs to be able to:

• call overloaded Java methods, and
• implement Java types with overloaded methods.

However, the typechecker rejects code with overloaded methods, except when overriding a Java method.

We’ve very often discussed relaxing this restriction in some sort of limited way, but never came up with anything very satisfying. Objections include:

• A natural mapping of overloading to Java means inheriting Java’s pretty messed-up rules about what is a legal overload. One could come up with a less natural mapping, but it’s difficult to come up with one that would result in reasonable semantics for binary compatibility across API changes.
• Similarly, it’s difficult to map overloading to JavaScript in a way that would result in reasonable semantics for binary compatibility across API changes.

@vietj has been complaining for literally years now that he wants Ceylon to support overloading in order to be able to do API generation in Vert.x. It turns out that in this use-case:

• the “natural” mapping is by nature just perfect, and
• we don’t care about JavaScript.

Finally, it has occurred to me that we could support overloading—with Java’s rules about what is a legal overload—just for classes and interfaces marked native("jvm"). This neatly sidesteps the objections above.

This should be rather easy to implement.

[jvasileff]

I think there is value in bringing readers’ attention to functions being overloaded, and in this respect I think an overloaded annotation would serve best

My thought exactly.

Although I’ve grown to really dislike overloading, I do acknowledge that it is very nice sometimes when writing code. I think its real harm is when reading, using, and maintaining code. An overload annotation would help, to highlight to readers/consumers that they probably need to review the other functions with the same name to really understand what’s going on.

Secondarily, when writing code, requiring each overload to be marked will help avoid accidental overloads, and overload is much easier to type and remember than the suppressed warnings annotation. (And, I think it just makes more sense than a warning.)

Both of these points are more important for Ceylon code, since the Ceylon mindset is that overloading doesn’t exist, so when both reading and writing code, you tend to be less aware of the potential for problems relating to overloading.

[gavinking]

OK, well fine, that is what I have implemented. Except #7143.