Returning many variables

[Andrzej Borucki]

How to deal with the elegant way of returning many variables. No pointers, no parameter reference, no make_pair.
Sample:
package sparse;

here is code moved from C++

public interface IPart {
	void copy_row(Row prow);
	int visit_col(Col pcol, int *rows_visited, int *cols_visited);
	int visit_row(Row prow, int *rows_visited, int *cols_visited);
	int sm_block_partition(Matrix **L, Matrix **R);
}

visit_col must fill row visited and cols_visited
sm_block_partition must returns two objects;

better is return object with two or three objects or additional methods like return_last_computed_by_other_method_rows_visited ?

[Zach Rode]

So I might be misunderstanding your question but why don't you return a collection or array? Those can contain objects or primitives(collections autoboxes primitives to their object type, just fyi)

[Andrzej Borucki]

Zach Rode wrote:So I might be misunderstanding your question but why don't you return a collection or array? Those can contain objects or primitives(collections autoboxes primitives to their object type, just fyi)

public interface IPart {
	void copy_row(Row prow);
	int[] visit_col(Col pcol);
	int[] visit_row(Row prow);
	Matrix[] sm_block_partition();
}

and if I wanna returns Matrix+Matrix +int? it simply Object[] sm_block_partition() ?

[Zach Rode]

yea you could return an object array just make sure you wrap the primitives into objects

[Fred Kleinschmidt]

A Method should NEVER return "many variables" unless they are truly a collection of the same kind of thing (such as an array of book names, a set of employees etc.).
You should have a class (or interface) that has getters for each distinct variable.

[Stephan van Hulst]

Agree with Fred. For tuples of values (as opposed to lists of values of the same type) you should create a simple class that encapsulates and accurately names those values.

There's a reason Java doesn't have general purpose tuple types (such as Pair, or Triple, etc.). They lead to code that's difficult to read because the members have stupid names such as item1, item2, etc.

[Tim Holloway]

Actually, the reason why Java doesn't return tuples is that it's object oriented, not "loose heterogeneous collection of things" oriented. And because it's strongly-typed and most tuple-returning languages such as Python and Perl are not.

While I suppose that you could define a syntax for strongly-typed tuples, the net effect would be something like a class anyway and you'd have to individually define all the tuple object variables. Doesn't seem worth the mess and bother. Especially since you can pass a class object around as a unit where you'd have downstream messiness if you returned a bunch of individual values.

[Piet Souris]

I do find myself writing on a regularly base a Pair<K, V> class, sometimes very handy. JavaFX does have such a class.

For an example of a class that has some variables defined, look at the IntSummaryStatistics class, a handy class that describes a few statistics of a set of data..

[Stephan van Hulst]

Handy, but as Tim has pointed out, it's not OO. The times I find I need to return a pair from a method are not so often that I can't write a quick class for it. Usually the class can be private (or even local), and therefore I don't have to add getters to it, just the constructor and fields.

[Piet Souris]

Well, it may not be OOP (why not?), but that is a very minor price to pay. But making sure your Pair class still works when used in a Set or Map, means defining an equals and a hashCode method, and perhaps a compareTo, making constructing it on the fly a tedious practice. But putting it in your personal library and adding your library to your project is also tedious. So my hopes are for Java 11. Also, if Scala, Kotlin and Python have it, it is time for Java to become market conform.

But we had this discussion before, I guess the twain shall never meet...

[Stephan van Hulst]

What would be the point of having different languages if they're all the same?

Tuples are not object oriented because as Tim has pointed out, they're heterogeneous collections that don't really encapsulate their contents well, and don't really have any behavior. The point of OO is that data is coupled with behavior, and that you ask the encapsulating object to operate on the data. Tuples just dump their stuff on the street for everyone to see. What's the difference with a custom return type? Custom types can make guarantees about their contents. Custom types can allow the caller to operate on the contents only in limited ways. Custom types have proper names for their contents.

I'd be worried if my methods need to return tuples so often that having a general purpose tuple type becomes a good investment. It kinda implies the code violates single responsibility.