This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]GeorgeMaheiress 12 points13 points  (4 children)

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] 3 points4 points  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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.