Method Signatures and Return Types

Miscellaneous Topics
#1

This one’s being bugging me for a while, why arn’t method signatures inclusive of return types?

I can’t have two methods in one class that only differ by return types though I can only differ in parameter type?

I realise this might be complicated to use but is there a practical reason why it isn’t supported? Until recently I assumed there was a technical reason why this wasn’t done since C++, Eiffel and Java don’t do it. However, I was just reading JSR 14 and noted that in some cases generics will produce byte code representing a class with two methods that only differ in return type. So the bytecode happily supports it but the language doesn’t?

Is it simply that it would be too complicated for us simpleton programmers to understand? The only thing that seems to be a problem is the ambuguities (sp?) caused but in other cases the compiler would simply flag these and expect the developer to resolve them…

Any thoughts appreciated,

Kev

#2

I’m just guessing but perhaps it this (note just an example):

Tuple
Color3f extends Tuple
Color4f extends Color3f

Foo class has the following methods:

Color3f getColor()
Color4f getColor()

Code has this:

Foo y = new Foo();
Color4f x = null;
x = y.getColor();

In this case which method gets called? x is both a Color3f and a Color4f. Could that be it?

#3

Yeah, this is what I was getting at with the ambuguities… isn’t this the same as having two methods in the Foo class that accept Color3f and Color4f tho?

void setColor(Color3f col);
void setColor(Color4f col);

Now if I did this:

Foo v = new Foo();

Color4f x = new Color4f(0,0,0,1);
v.setColor(x);

Kev

#4

Hmm, that hadn’t occured to me. It does appear to be the same thing. The compiler must choose the method with a parameter “closest” to the passed object. Suppose it could do the same for return types. In that case would casting override the choice the compiler nomrally makes?

#5

Return type IS a part of signature in jvm. It is just java-the-language which does not allow to differentiate between them. Why ? Probably because C++ works in same way, because it is easier to pay attention to argument type than to variable which is assigned to and because it would require very strange syntax in case you are ignoring return type - probably something like


(String)obj.doSomething();

Anyway, support for it is inside jvm - and this is the reason why covariant return types were so hard to put into java (introduced into JDK 1.5 with ugly hack going behind the scenes).

#6

Yeah, thats what I read in the JSR. The reasoning that its that way in C++ makes perfect sense, but being a C++ engineer for a living I couldn’t help but question why its that way there. So far, still no technical reason, simply that it’d make it more intricate.

Kev

#7

[quote]Yeah, thats what I read in the JSR. The reasoning that its that way in C++ makes perfect sense, but being a C++ engineer for a living I couldn’t help but question why its that way there. So far, still no technical reason, simply that it’d make it more intricate.
[/quote]
I used to get screwed over by several such “features” of java, which are REALLY useful (one might even say “essential”) when developing libraries. The other major one was the lack of parametric function despatch (it’s complex to explain, but according to the design of OO as a concept it’s reasonable and arguably logical to expect).

Only have vague memories now, but … In all my attempts to find reasons why these weren’t supported by java, the best answers I remember getting were along the lines of “think about how you’d implement the method despatcher, and the performance penalty you’d pay for the extra work for the VM to decide which method to call”.

ISTR that, like with goto’s, there were optimizations that couldn’t be done if you allowed this in the JLS. I can’t remember what they were any more :), although IIRC parametric fn-despatch made it difficult to keep lookups down to single pointer indirection in a typical fn-table implementation.

…but I always hoped the JVM’s would evolve enough that we could have a more powerful JLS (v.3.0?).

As for clarity, it’s certainly a two-edged sword; it gives power to make some really hard to debug mistakes, but OTOH this level of polymorphishness (!??) makes 3rd-party library dev sooooo much easier (and eliminates several of the hacks you currently have to do to work around these “features” in the JLS :().

#8

Okay, then what does THIS call?

public void dumbmethod(){
getColor();
}

Remember, returns are optional. The syntax doesn’t require you assign them anywhere. Without an assign, there is no return type to match.

Hope that clears it up.

JK

#9

Agreed,

However, I’d expect to see the compiler flag the ambiguity and ask the developer to indicate which one they meant. I’m not saying there wouldn’t be problems with the compiler not knowing what to do but then as illustrated above there are already some and it seems odd that they arn’t dealth with consistantly.

But then thats just an opinion, the example is another case where it would be more intricate for the developer.

Kev

#10

I think this gets into compiler/language designer preferences. I’m of the opinion that ambiguities in a language should be avoided if at all possible. Certainly the meaning needs to be deducible from the source. It would seem to me that the only other option would be to disallow the call without return entirely or require a cast at least and then have the legality of that cast only be deducible at run-time by comparison against the called classes methods.

All in all seems like a mess to me much better solved the way it is. But maybe I’m missing something.

#11

No, No, I don’t think you’re missing anything. It could well just be thats its more convienient this way. I just found it odd one day looking at a piece of code that paramaters are treated one way and return types another. But I guess you’re right, its just an harded to describe which one you meant with a return type:

myInstance.doSomething((Color3f) param);

vs

(Color3f) myInstance.doSomethingElse();

It made me a bit suspicious tho when not only java but C++ and Eiffel do it this way. Maybe everyone came to the same decision, or maybe there was an actual technical reason why it isn’t done…

Ah well :slight_smile:

Kev

#12

AFAIK, Eiffel does not even support argument overloading. You need different named methods for different parameters.

On the other side of fence is Perl - you can make function behave different depending on what type of variable is expected in receiver site. So same function can return number of elements which fit to given rule if you assign it to scalar, or list of such elements if you assign it to array. Ugly, isn’t it ? :slight_smile:

#13

Been a long time (well few years) since I did Eiffel so I guess I’m wrong.

In Perl tho (which I also haven’t done for ages, Java appears to be a one way street for me :)), isn’t the munging of the return type actually due to the dynamic typing of the langauge. The function doesn’t actually decide what to return based on the reciever. It returns what ever it likes and back where its actually assigned to the recieving variable is mangled into what ever shape they want it to be, all at runtime (shudder).

Kev

#14

I have never written any serious perl code, but isn’t following snippet checking for context and returning different things depending on it ?


given want {
        when List   { return allPeopleHere(); }
        when Scalar { return numberOfFishInTank(); }
        when Void   {  launchRocket();   return; }
    }

If I return list, I can understand it can be autoconverted into scalar. But I’m worried about ability to write function as above - which work totally different depending on caller context.

#15

Cooo! That really is hideous! :slight_smile: Not because the reciever type can decide what the method does but because the compiler/interpreter? doesn’t have a chance to question the developer when their not absolutely specific about which one they mean.

Frightening! I just mentioned it a collegue who’s slightly mad about Perl and even he looked slightly worried :slight_smile:

Kev

#16

Ayup this idea of “context” is what makes PERL write-only in my book.

It can be very convenient to write but really really hard to understand when read.