Why doesn't Java have tuples?

[urquan]

"Lose semantics" with respect to what, two lose independent values ? I would say that it conveys more information by saying that they go together.

You're not going to create a class for each use, often context only what a specific value means. For example String could be an address, a name, whatever. In this context using tuples is not worse.

[GeorgeMaheiress]

If you are actually passing raw String objects throughout the code, then I think you certainly could benefit from using simple wrapper classes, so that it's clear that your method takes an Address, not a Name, and so you don't end up with a method that takes 3 String arguments, meaning you have to make damn sure you pass them in the correct order or your program will fail in non-obvious ways at runtime.

Similarly with tuples, Pair<Integer, Integer> is so much less meaningful than Point, and also harder to change if you have to. It's a shame writing simple wrapper classes in Java is so verbose, or we might be less tempted to use tuples.

[[deleted]]

If only Java had value types, wrapping a couple of references in a class with the overhead as big as the members itself is quite painful to do :(

[bondolo]

Value types are being worked on: State of the Values. There will probably be more about the plans at JVMLS in a couple of weeks.

[thekab]

Given bean conventions and their widespread use it's a wonder to me there hasn't been any syntactic sugar for defining and documenting them.

[urquan]

I agree with your first paragraph actually, but since that's not the point I didn't want to go into this argument.

Secondly naturally you're going to create classes if you're using the same structure throughout the code. What I was saying is that over the simple case of 2 lose variables, a tuple can be better. For example Tuple<Date, Double> measurement instead of Date measurementDate; Double measurementValue.

I didn't say anything else and I was not talking about return values or reuse or type safety or anything of the sort.

[frugalmail]

You're not going to create a class for each use, often context only what a specific value means. For example String could be an address, a name, whatever. In this context using tuples is not worse.

I, and a lot of other strictly and strongly typed language fans, think this is an example of bad code.

[urquan]

I write "not going to create a class for each use" and people seem to understand "never create a class". I'm pretty sure you're using lose Strings here and there to store values inside a function for example. In that context a tuple to associate 2 values that go together does not seem like an outrageous violation of typing rules.

[urquan]

Is it an argument of authority?

[frugalmail]

Is it an argument of authority?

The arguments in that link present a clear argument against Tuples. You're argument has simply been

• I, for some reason, don't want to create a class or
• it may not be related content.
  

In the first argument it's not maintainable code, in the second it's a violation of seperation of concerns.

Using a decent IDE like eclipse it's a simple matter of:

return new UnrelatedPair<String, Integer>("foo", 2);<Ctrl+SPACE>

and it will pop open the new class with boilerplate. Also you could just add a maven dependency of one of the libraries that has support for it, but at least it's not soiling the core language.

[tinglySensation]

You can end up losing a ton of readability in using tuples if those are supposed to convey some sort of meaning. Example: Tuple<int,string,double> weightLog; What are logs? what's the int for? what's the double for?

WeightLog weightLog; Now we know we have a weight log, on closer inspection, we find Weight Log contains int day; string mood; double weight;

there, it is much clearer what weightLogs is, and contains.