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:).