discussion: should hashcode be calculated based on order

[jarlah]

What concerns me is that changing hashCode in such a big way can affect other parts of vavr, like equals. However, it seemed to not make any difference to comparing the same two (different) hash maps I made a test for with assertThat(...).isNotEqualTo(...), which is also the example from #2733

In addition, this Collections.hasOrdered and Collections.hashUnordered is used many other places. Should we change them too?

Look at this as a discussion PR, more than actual fix.

DONTMERGE :) (unless it was an ingenious fix, which I doubt)

PS! is this project used actively still? to be honest, I would rather use vavr than mock around with streams and collect and wierd reduce mechanics.

[pivovarit]

LinkedHashMap is still just a HashMap with an insertion history, and that's also how JDK treats it:

var m1 = new LinkedHashMap<String, Integer>();
var m2 = new LinkedHashMap<String, Integer>();

m1.put("a", 1);
m1.put("b", 1);
m2.put("b", 1);
m2.put("a", 1);

System.out.println("m1.equals(m2) = " + m1.equals(m2));
System.out.println("m1.hashCode() = " + m1.hashCode());
System.out.println("m2.hashCode() = " + m2.hashCode());

so a natural course of action is to stay consistent with this approach and use ordered hashing for data structures that rely on the ordering of elements