5 ms·
tl;dr Java needs to be able to decide which overloaded method implementation to use at compile time, meaning you can't differentiate between method implementati
by nebulous1 10y ago
tl;dr Java needs to be able to decide which overloaded method implementation to use at compile time, meaning you can't differentiate between method implementations based on return type alone. However, when compiled to bytecode, each method and method call includes the return type as part of the method identification, so Java bytecode is actually capable of differentiating between implementations with the same name based on return type alone. This fact is used by bytecode obfuscators, and can lead to bugs in decompiled code if the decompiler doesn't account for it.
- masklinn 10y ago> Java needs to be able to decide which overloaded method implementation to use at compile time, meaning you can't differentiate between method implementations based on return type alone. That's not correct. Rust has no issue statically dispatching based on the return type. Java-the-language does not allow it so it does not have to deal with calls which don't use the return value e.g. int getSomething() String getSomething() If the return value is not used, you have to explicitly disambiguate this call somehow, and Java provides no way to do so.
- bradleyjg 10y agoEven if you have a language that forces you to assign the return value, what does the compiler do in a situation like: Integer getSomething() String getSomething() when the calling site is: Object something = obj.getSomething();
- tazjin 10y agoThe compiler would tell you that it can't disambiguate that and fail. It's a type error.
- bradleyjg 10y agoI guess that makes sense. It is similar to: void putSomething(Integer i) void putSomething(String i) and obj.putSomething(null) which I think throws a compiler error in java.
- Filligree 10y agoThe Haskell solution is to require a type annotation if the type is ambiguous. Of course, Java provides no way to do that.
- Manishearth 10y agoWell, I presume `String something = getSomething(); Object s = (Object)something;` would be okay. Note that in Rust we don't have inheritance (not exactly the same kind, at least), so it's rare where a statically typed value can be referred to with a different type. So there are still annoyances in Java with this approach that Rust wouldn't have.
- areyousure 10y agoThis and other questions are discussed at http://stackoverflow.com/a/442291 http://stackoverflow.com/a/442291
- deleted 10y ago[deleted]
- nebulous1 10y agoWhat's not correct? I said Java needs to decide the return type, not Rust, or some other language.
- paulddraper 10y ago> Java needs X, meaning you can't Y X and Y are certainly both possible, even if the Java languages chooses not to have Y.
- kelnos 10y agoParse error: implicitly the author intended "Java needs X, meaning you can't Y in Java". Please read charitably and give the poster the benefit of the doubt.
- masklinn 10y ago> Parse error: implicitly the author intended "Java needs X, meaning you can't Y in Java". Except the second clause does not generally follow from the first yet is presented thus. You can't Y in Java because Java very specifically decided not to support Y.
- paulddraper 10y agoThe correct statement is 1. Java needs X. 2. Unreleatedly, Java chose not to Y.
- masklinn 10y agoYou're stating "you can't differentiate between method implementations based on return type alone" which is nonsensical both on its face (people have no issue doing it) and technically (since several languages do exactly that). And thus "Java needs to be able to decide which overloaded method implementation to use at compile time" is not an issue relevant to return-type overloading. There was no issue with Java implementing return-type overloading, the creators of Java decided not to do it for non-technical reasons.
- 10y ago
- justin_oaks 10y agoIt could be allowed. Consider the case of var-args method called with a null value. Say you call the method ambiguousNull(String ...args) like so: ambiguousNull(null); Should args be null? Or should args be new String[]{null}? In the absence of any more information the compiler chooses the first, but may still issue a warning. But you can clearly disambiguate by casting: ambiguousNull((String)null); // args is null ambiguousNull((String[])null); // args is a 1-element array
- guelo 10y agoSo given int something() { } String something() { } A hypothetical calling syntax could be (int)something(); Or the compiler could even choose one for you with a warning. Seems like a good suggestion for Java 10.
- lgas 10y agoIt seems like a in the case of var args, the args should always be an array, since the meat of most var args based functions is iterating over that array.