Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Multiple return types for Java 7
At 11:13 AM on Dec 3, 2007, chhum wrote:
Fresh Jobs for Developers Post a job opportunity
The subject has been raised and debated before. A bug was logged as far back as 1999 and closed without being fixed.
During an interview in 2000 James Gosling has stated it was something he wished he'd added in.
Given the number of other changes being kicked around for Java 7 is it time to put this one back on the agenda?
81 replies so far (
Post your own)
Re: Multiple return types for Java 7
I'm not necessarily against this RFE but I don't think it is as big a deal as you make it out to be. I just create a class to hold the multiple values I wish to return and make the method return an object of that type.Re: Multiple return types for Java 7
I prefer C# style "out" parameters (or even "ref" parameters). Either would solve the problem nicely, IMO, w/o overcomplicating the syntax.Re: Multiple return types for Java 7
I don't feel they're necessary... create an object and return it... easy enough.Re: Multiple return types for Java 7
> I don't feel they're necessary... create an object> and return it... easy enough.
I agree, I do not see a need for more. What am I missing ?
Re: Multiple return types for Java 7
Yes, I agree with the above comments, I don't see a need.If you want to return more than one value then you have an OO requirement for an object, if not, then perhaps your method is overloaded and doing too much?
At the very least you could work around it by passing in a List surely?
Re: Multiple return types for Java 7
NoRe: Multiple return types for Java 7
All we need is some tuple syntax, that wraps something like a Pair.For example:
public static (double,double) solveQuadratic(double a,double b,double c)...
Which would be 'desugared' to Pair<Double,Double>
For larger tuples, either tuple types could be generated by the JVM or the compiler, or nested pairs could be used. For example, (int,double,String,JFrame) would be desugared to:
Pair<Integer,Pair<Double,Pair<String,JFrame>>>
The only difficulty then is that generics doesn't support primitive types, so perhaps the above tuple would need to look like (Integer,Double,String,JFrame), sadly.
My vote: tuples AND generics supporting primitive types. Neither require a VM change, and neither invalidate old code. Try tuples out now in Scala.
Re: Multiple return types for Java 7
1) I think forcing developers to come up with their own return types leads to more readable code (Pair is hard to read).2) I agree that Generics requires some cleaning but I'm not sure this is directly related to the RFE this post is discussing.
Re: Multiple return types for Java 7
Sounds like a great way to make unreadable programs.What do you mean lack of pointers? Everything that is not a value type is a pointer in Java. Or object reference rather. Java has structs, classes, arrays, inner classes, anonymous classes, collections (and even closures soon): use them well and you will never crave for multiple return types.
Re: Multiple return types for Java 7
> 1) I think forcing developers to come up with their> own return types leads to more readable code (Pair is
> hard to read).
I'm not suggesting that Pair appear in source code, but in the implementation. It is merely a way of implementing tuples without changing the VM.
> 2) I agree that Generics requires some cleaning but
> I'm not sure this is directly related to the RFE this
> post is discussing.
Sure, but if generics were improved this idea would be more natural in use.
Re: Multiple return types for Java 7
There have been many times have wanted to be able to return multiple values and have to resort to returning a list (and losing type safety), having to create a special object to hold both values, or making two separate method that have the same logic but return different types . I don't really like any of these solutions because they add a bunch of unnecessary code. So I am all for being able to return multiple values from a method.Re: Multiple return types for Java 7
Tuples, etc, could be nice here, but the main issue is how self documenting the resulting API is -- or more to the point here, isn't. Returning n-tuples from some private method is well and good. Returning n-tuples from a public method leads to a very hard to comprehend API. At that point it is better to (1) look for a simpler API option and (2) if that's not possible create and document a data-holding class and return it.Re: Multiple return types for Java 7
I disagree with almost everything you said. Creating objects or data structures (List, Array) for returning complex values is neither bloated nor unecessary. In over 10 years, I've only met this need like... two times, easily solved by creating a readable and understandable data structure.Multiple return values are prone to abuse. If you are returning a set of related values, then their relationship should be made explicit by means of a class. If they are unrelated, then clearly there's something sloppy about that function.
So by all means, keep this tuple stuff out of Java.
But I would like to see array literals with inferred types added, so you could write return { 3, 4 }; if you need it so badly.
Re: Multiple return types for Java 7
Tupels are nice, but while you mention Scala: Structural types are even better:public {double a, int sgn(double d)} getFoo();
Could then be then be received by a type
{double a} result = obj.getFoo();
print(result.a*100);
This would make Java's declaration hell a bit cooler and it will work very nice together with closures/first-class methods.
Perhaps a little sugar for positional binding could be made
double x=getFoo(); //binds types by position