pivovarit
commented
1 month ago 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
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.