Vavr: Make Tuples DTO friendly - add getters

[rumatoest]

It will be very nice to add getters for tuple values.
I want to call tuple.getSecond() or tuple.getValue2() or tuple.getV2() instead tuple._2

The reason is that there are many frameworks that can work with java objects only using standard getters convention.

I can make pull request if you are agree with my notions

[chb0github]

If it is to follow the getter convention, then it should be tuple.get_1() and tuple.get_2()
This would cause it to manifest itself in json as

{
   "_1" : "Foo",
  "_2" : "Baz"
}

[rumatoest]

@chagmed No it is not, because properties naming convention against such weirdo thing like _variable or _my_java_var_name (it is not python)

[rumatoest]

@chagmed No it is not, because properties naming convention against such weirdo thing like _variable or _my_java_var_name (it is not python)

[danieldietrich]

Thank you for your suggestion. We will keep it this way, see this comment.

[danieldietrich]

Vavr's values, i.e. 'data holders' are stateless and immutable. This manifests by having only final instance variables.

_Note: there are exceptions, like Future, Iterator, Lazy and Stream. These are stateful._

public class SomeValue<T> {

    // most of the time private, in the case of tuples instance variables are public
    final T abc;

    // Vavr's constructors are not directly called
    private SomeValue(T abc) {
        this.abc = abc;
    }

    // instead we use factory methods, often more than only one
    public static <T> SomeValue<T> of(T abc) {
        return new SomeValue(abc);
    }
}

Given that we are not able to follow DTO or Bean conventions:

• having setters would imply to have non-final instance variables, which is a no-go for Vavr
• having a default constructor would also imply to have non-final instance vars (see above)

Namely, we could only have getters. But they do not make any sense, we would only have them because some Java developers feel more comfortable with the name 'get'.

We are intentionally breaking these old structures. However, when Java evolves (e.g. by introducing value types / data types), we will align Vavr to Java and benefit from these types. Tuples may then look like this:

data class Tuple1<T1>(T1 t1) {}
data class Tuple2<T1, T2>(T1 t1, T2 t2) {}
data class Tuple3<T1, T2, T3>(T1 t1, T2 t2, T3 t3) {}
// ...

I hope you understand my points. I will close this question now (and your follow up #2140).