Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Method Signatures and Return Types  (Read 2025 times)
0 Members and 1 Guest are viewing this topic.
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Posted 2004-01-29 12:00:15 »

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

Offline zparticle

Senior Member




Thick As A Brick


« Reply #1 - Posted 2004-01-29 13:42:55 »

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?

Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #2 - Posted 2004-01-29 14:00:00 »

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

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zparticle

Senior Member




Thick As A Brick


« Reply #3 - Posted 2004-01-29 14:09:43 »

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?

Offline abies

Senior Member





« Reply #4 - Posted 2004-01-29 14:16:38 »

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

1  
(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).

Artur Biesiadowski
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2004-01-29 14:27:37 »

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

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2004-01-29 15:48:34 »

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.


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 Smiley, 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 Sad).

malloc will be first against the wall when the revolution comes...
Offline Jeff

JGO Coder




Got any cats?


« Reply #7 - Posted 2004-01-29 16:50:32 »

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

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #8 - Posted 2004-01-29 16:57:13 »

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

Offline Jeff

JGO Coder




Got any cats?


« Reply #9 - Posted 2004-01-30 00:27:01 »

Quote

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.


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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #10 - Posted 2004-01-30 06:13:32 »

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 Smiley

Kev

Offline abies

Senior Member





« Reply #11 - Posted 2004-01-30 06:19:48 »

Quote

It made me a bit suspicious tho when not only java but C++ and Eiffel do it this way.


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 ? Smiley

Artur Biesiadowski
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #12 - Posted 2004-01-30 06:41:37 »

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 Smiley), 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

Offline abies

Senior Member





« Reply #13 - Posted 2004-01-30 07:22:35 »

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

1  
2  
3  
4  
5  
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.


Artur Biesiadowski
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #14 - Posted 2004-01-30 07:34:17 »

Cooo! That really is hideous! Smiley 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 Smiley

Kev

Offline Jeff

JGO Coder




Got any cats?


« Reply #15 - Posted 2004-01-30 20:50:17 »

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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (57 views)
2014-04-15 18:08:23

BurntPizza (55 views)
2014-04-15 03:46:01

UprightPath (68 views)
2014-04-14 17:39:50

UprightPath (51 views)
2014-04-14 17:35:47

Porlus (68 views)
2014-04-14 15:48:38

tom_mai78101 (93 views)
2014-04-10 04:04:31

BurntPizza (153 views)
2014-04-08 23:06:04

tom_mai78101 (249 views)
2014-04-05 13:34:39

trollwarrior1 (205 views)
2014-04-04 12:06:45

CJLetsGame (213 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!