Vavr: Tuple properties should be named in Java way not Python

[rumatoest]

How can you come with this idea of naming properties in tuple tuple._1 tuple._2 etc.

Yes I knot that Java allows to do it, it also allows to name methods like do_some_action() and make double underscore variables, but cool devs do not do it.

I suggest you to rename tuple properties in Java vay like tuple.v1 instead tuple._1 and add proper getters to it.

For now it is much comfortable to use Apache commons Tuples/Pairs etc. because they do it in Java way.

[alwins0n]

It is the scala way. Since vavr is greatly influenced by scala it makes sense to leave it like that

[rumatoest]

it makes sense to leave it like that

No it does not. There are some conventions in Java and Java devs should follow them or switch to other language.

[chb0github]

Rumato: as soon as I saw it I knew it was from Scala. The whole library is
essentially Scala envious. You're also missing that those are public final member variables which, while is legal syntax, is also generally not
done in Java though this use case is totally safe and quite terse.

Changing the member symbols for tuple would be a breaking change. It should
be clear to you as a professional that once a standard is set it takes a
divine act to change it. If you weren't around when those standards were
set you have no input. This observation doesn't just apply to vavr

Have you seen the inner code from major spring projects? Better to focus on
the functional aspects that vavr provides the community at large rather
than the implementation details.

On Sat, Oct 14, 2017, 5:13 AM Rumato Estorsky [e-mail]
wrote:

it makes sense to leave it like that

No it does not. There are some conventions in Java and Java devs should
follow them or switch to other language.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/vavr-io/vavr/issues/2140#issuecomment-336631111, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABaI0BF8L_Ve9aT0Oc0juC9fALsMhgNaks5ssKVqgaJpZM4P5SzL
.

[rumatoest]

Changing the member symbols for tuple would be a breaking change.

I already saw breaking changes in latest commits , thus I do not thing that this is a big deal until version 1.0 , because vavr developer already doing this.

BTW there are no getters for those public final member, so it is possible to add getters with valid names.

[alwins0n]

hmm now that i think of it, maybe the members could be named "first", "second" and so on with respective getters. also since they have a map1and put1 etc they should have a get1...?

[rkraneis]

Well, first and second ... eighth are still ok, but what's with seventeenth and twentyfirst (if max_arity ever increased)? As much as I like descriptive names, t.first, t.second, t.third don't stand out as well as t._1, t._2, t._3 (or t.e1, t.e2, t.e3). Having getters and setters would only make sense if one wanted to enforce this as a contract in an interface. FWIW t.e1, t.getE1, t.mapE1 would look ok-ish (I'd prefer e (element) to v (value) as that is more in line with usage in the collection API) ...

[rumatoest]

but what's with seventeenth and twentyfirst

IMHO if you require such big tuple, than probably you have some issues in your code :) But nevertheless t.e1 or any letter prefix is better than underscore. In this case t.p1 is very-very javish because "p" is for property :rofl:

[rkraneis]

Well, scala doesn't only go up to eight, or eleven, it goes up to 22 ;-P But yes, using those kinds of tuples should be reserved to clojure.

[chb0github]

@rkraneis this goes to issue #2137 : vavr is really trying too hard to be "scala-for java" and a lot of things don't make sense when you have entirely different language constructs. If you have a "Tuple" of airty 18 then you have a full-on class. Once you start clustering groups of values together it's called a _class_ and Java and Scala are full of means off handling this.

IMO arity of 2, 3 and maybe 4 is ok because after that you need a class. Vavr can and should draw inspiration from Scala's collection libraries because it fills a gap in the Java native APIs. But the libraries need to target the Java platform and it's idiosyncrasies

BTW:
Tuple: 2
Triple: 3
Quadruple: 4

[hamnis]

I have found Tuples useful up to Arity 27 =)

[chb0github]

A "Tuple" of arity 27 is a Map of something like Map.of("_27","27th thing") with that much arity practical use of such a "Tuple" is essentially 0. If you weren't the guy who wrote the original code you would have no idea what semantic value _27actual had.

[hamnis]

Everything depends on context. If you are for instance decoding|encoding Json, as I am in this case, then it becomes useful. Since each field may be of a different type, I want to be type safe as far as possible. A map is not.

[danieldietrich]

Tuples are special Records, both are product types. A heterogenous list (short: HList) is a recursive declaration of a Tuple.

We thought about HList but it isn't practicable.

Record types for Scala are currently researched.

Our Tuples have accessors and 'functional setters':

• public final fields _1, _2, ... - this is the idiomatic way to access tuple values

K key = entry._1;

• methods _1(), _2(), ... - this is the idiomatic way to access values using method references

Seq<K> keys = myMap.values().map(entry::_1);

• update1(T1), update2(T2), ... - to replace by element of same type

• map1(Function), map2(Function), ... - to replace by element of different type

---

As @alwins0n already said, we intentionally aligned to Scala here. When introducing getters, someone will ask for setters (instead of update*). Then the purely functional political party will say that setters imply mutable state.

I think the idea of classical Java beans does not fit well here. Beans (aka DTOs) need a no-arg constructor, getters and setters, in order to be useful (e.g. for automatic marshalling/unmarshalling). We intentionally do want to stand apart from this.

I do not want to invent s.th. new here, it is our premise to align to Scala, especially when in doubt. Talking about names directs us to nowhere. There are too many opposing opinions, it is impossible to find consensus.

[rumatoest]

I think the idea of classical Java beans does not fit well here. Beans (aka DTOs) need a no-arg constructor, getters and setters

Huge amount of frameworks in JAVA rely on getVALUE methods (does not matter is it purely DTOs or not) it is just a right way to get property of object.

[chb0github]

I think what Daniel is saying is that vavr is intended to be a Scala
immutable library implementation in Java. Following a Java convention for
sake of easy integration at the expense of being an academically pure
excercise is not of interest.

There is a vavr Jackson module, as an example. Which demonstrates that
framework integration is possible but not for free.

Save your breath Rumato. Your request doesn't align with the vision of vavr
set forth by the founders.

On Tue, Oct 24, 2017, 2:23 AM Rumato Estorsky [e-mail]
wrote:

I think the idea of classical Java beans does not fit well here. Beans
(aka DTOs) need a no-arg constructor, getters and setters

Huge amount of frameworks in JAVA rely on getVALUE methods (does not
matter is it purely DTOs or not) it is just a right way to get property of
object.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/vavr-io/vavr/issues/2140#issuecomment-338929343, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABaI0EdOuoDQDvYq9oHUAVzR_i0-YQYGks5svayUgaJpZM4P5SzL
.

[danieldietrich]

Closed for the same reason as #2138 (see my comment).