[interface]

JEP draft: Better hash codes
http://openjdk.java.net/jeps/8201462

#interfacesmieci

[n.....y]

@interface: W sumie to o co chodzi... Nie czaje... Ja bym wolał aby equals nie przyjmował typu Object

[b.....7]

@nie_tuzinkowy: dlaczego?

[n.....y]

@boo007: Bo mozesz porpwnac np Person o z Order o i te klasy dziedzicza po equals...

[b.....7]

@nie_tuzinkowy: ale jak napiszesz np.
Person a = new Person();
Object b = a;
to co powinno zwrócić a.Equals(b)?
Moim zdaniem było by z tym więcej problemów.

[n.....y]

@boo007: Moim zdaniem nie powinno sie wywolac wtedy a.equals(b) juz na poziomie kompilacji...

[b.....7]

@nie_tuzinkowy: wtedy masz problem z np. HashSet-em, jeśli chcesz przechowywać elementy różnych typów. Wszystkie implementacje wykorzystują metodę Equals do sprawdzania kolizji. Pewnie dało by się to obejść, ale trochę za dużo zabawy moim zdaniem.

[interface]

HashSet-em, jeśli chcesz przechowywać elementy różnych typów. Wszystkie implementacje wykorzystują metodę Equals do sprawdzania kolizji

@boo007: hashset jak nazwa wskazuje używa hashCode jako "wartosci" obiektu. gdyby hashSet uzywal equals do porownania obiektow to big O operacji add byloby O(n), bo musialbys za kazdym razem porownac nowy obiekt do istniejacych w hashsecie, hashSet add ma O(1), contains też ma O(1) a przy equals byloby best scanario O(1) worst scenario O(n).

[b.....7]

@interface: równe hashCody nie dają gwarancji, że obiekty są równe, dlatego zawsze jest używana metoda Equals do upewnienia się, że oba obiekty są rowne.