Say no to multiple return types in Java 7

I disagree with you. Using multiple return types could save much time as it can avoid specific object creation only for that method. According to me it will be very useful.

I agree, I don’t think it is necessary to add yet another feature to the language. I’d say once every 3 projects I write I might run into a situation where multiple return types would be nice, but after 5 mins of adding a “struct” like static class to hold the return params and I’m off to the races.

NO!

There I said it.

Just return a bean if you need to return multiple values. Multiple return types is PerlCrap ™

Just use a “good old Map” i.e.

public Map doSomethingAndReturnSomething() …

Cheers,
Dmitriy.

This is scary stuff – simply for the fact that such major changes to the language are most likely going to be compile-time conveniences – much like generics which has no runtime type parameterisation, and has left holes in the implementation. I fear the same thing will happen to these other proposals. This breaks the common sense object technique of isolating responsibility – what ever happened to simple conditional statements? This and the ridiculous ideas of operator overloading, closures etc need to be binned before they get any traction. Use Groovy if you want these benefits and leave the language alone.

We already have stretched the notion of valid return types in java 6, enough is enough. Anyone who has tried to study for the java exams will know how complex the language already is, and how it has steadily gotten more complex.

Change for the sake of it will ruin Java before anything else. IF anything, it needs to be simplified!

You can also use generics for type safety.

If you have a type Pair<L, R> you can return…

Pair<String, Double> foo()

or

Pair<Long, List<String>> bar()

I completely disagree. This is one of the few Java language enhancement proposals that REALLY makes sense. Returning an array or a map is ugly, and explodes what should be a simple operation into a multi-line ordeal full of unneeded object access and casts . Multiple return values is much clearer and much simpler, and it’s type-safe on top of that.

Multiple return types is an obvious win for Java.

“why not just return an Object[]” — well, it’s not type safe, it’s verbose and it’s a little bit ugly to read.

When code is written in a style that favours immutable objects, you often seem to need multiple return types. There’s another style where you can just pass in multiple mutable objects into a method. I guess it’s a matter of taste, but I prefer the former.

To give an example of where I’d want multiple return types in real code, suppose you wanted to take a list and process it according to a boolean condition; maybe a list of Strings, and you want to determine which are well-formed email addresses and which aren’t, and you want to keep the results around. You could have a method with a signature:

public void wellFormed(List inputs, List valid, List invalid>) {…}

Called like:
List valid = new ArrayList();
List invalid = new ArrayList();
wellFormed(inputs, valid, invalid);

Personally, I don’t like that so much. I’d like it if Java let you do something like:

List, List wellFormed(List inputs) {…}

And called like

List valid, List invalid = wellFormed(inputs);

It can be handy sometimes, especially when you can also use closures and can thereby write functional style recursive algorithms. However, you can allready make a Tuple-class to hold two objects. You can nest them:
Tuple>, etc.
Object[] is ofcourse also possible, but with the use of generics it would be easier to understand what’s going on.
As with closures, I think you can best use these things on private algorithm-like methods and you should not use them on public methods that represents the model.

Together with closures, multiple return types can help to write efficient functional programming style recursive algorithms.
Object[] is a way to allready use multiple return types. Beter perhaps is to make a Tuple-class that can store two objects. You can nest them:
Tuple>.
Use these things to make smarter and more initiutive algorithms, but don’t use them in your OO-design.
Perhaps an idea is to allow use only on private methods.

Is see that his blog can not copy with generic java syntax. I meaned Tuple[T,T] and nesting like Tuple[String,Tuple[Integer,MyObject]]

We don’t have it, we have just several more or less ugly, slow and work wasting ways how to emulate it.

Old good arrays are not typesafe when you need to mix returned types, you can’t mix object with primitives (dont want make yet more rubbish with boxing, thanx..). You have to create one-purpose object, populate it by hand and then take values out, lots of code noone can write…

Old good Map are just slower and more hunger variant of arrays.

Next posibility – old good java object – again, lot of code for just one purpose I realy don’t want to write.

Thanks for all that, but still voting for MRV, fast, typesafe, elegant, without tons of one-purpose rubish…

Btw. veery long debate about mrv is here – http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792 – if you want something to read:).

Note: When I mention “multiple return values” I really mean “multiple return values/objects/etc. that can each be comprised of different types/classes.”

Multiple return values would be a very useful productivity feature in the Java programming language. Although I agree that in the vast majority of circumstances it’s not needed, the occasional use can reduce a lot of extra programming where a separate class/array/list is created *only* to handle multiple parameters simultaneously (which is also extra overhead that I’m not keen about because in loops it can increase the computational expense exponentially).

Another reason multiple return values is needed is to work-around the pass-by-value limitation when dealing with primitives. Of course, specifically supporting pass-by-reference is not a substitute for every scenario that can benefit from multiple return values, and partly because it is more natural for people to understand that what was returned has probably changed, where with pass-by-reference scenarios it isn’t always clear without good documentation (unfortunately most people are terrible at writing good code documentation/comments/etc.). So, if I had to choose between supporting pass-by-reference v. multiple-return-values, I would choose multiple-return-values.

The argument that the code is more difficult to read is rediculous in my view. Code that’s difficult to read is usually due to sloppy coding style [with lack of comments] anyway (if you want to see first-hand, just ask on IRC at irc.freenode.net#perl for some examples, or search Google.com for the keywords “perl” and “obfuscate”).

Here’s a sample of one way I think such code could be constructed to support multiple return values, which is still easy to read and understand:

int aA = 1; // Arbitrary value number one
int bB = 2; // Arbitrary value number two
aA, bB = swap(aA, bB); // Swap arbitrary values

// The swap method, which is really REALLY simple
public int, int swap(int first, int second) { return second, first; }

If implemented with flexibility in mind, multiple variables could be defined in a similar manner, for example:

int aA, int bB = 1, 2; // Arbitrary values

Now, I don’t know what Sun/Oracle will decide regarding the final syntax for dealing with returning multiple values, but even if there are some special brackets surrounding the sets of values, it will still be pretty straight-forward to read.

Either you dont return multiple values- or you do.

Returning a list or a map to return multiple values is nothing but a hack.

If you have to return multiple values (which I candidly think is a genuine need) you might as well return multiple values from a method

Hey, very nice website. I actually came across this on Google, and I am really happy I did. I will definitely be coming back here more often. Wish I could add to the post and bring a bit more to the table, but am just taking in as much info as I can at the moment. Thank You

people who oppose multiple return need to wake up and think about they say for a moment

return an array of object is way more unreadable. And creating a class to enable the multiple return out of a function is just stupid idea and lots of unnecessary work

multiple return types will enable compilation time check too. Way better than return an array of objects and cast each one …