Здравствуйте, netch80, Вы писали:

scf>>>Это вопрос дизайна языка. equals/hashСode в Object подталкивают программистов к их переопределению в собственных объектах, тем более, что equals почти всегда нужен, а правила соответствия equals/hashСode вдалбливаются начинающим программистам с самого начала изучения языка.

vsb>>Не знаю, я вроде не начинающий программист, но меня это никуда не подталкивало никогда. Если реально нужен equals — переопределяю. Если объект в виде ключа в хеш-таблице используется — переопределяю hashCode.

N>Правила таки о том, что это надо делать одновременно. Если ты переопределил hashCode() => переопредели и equals(), и наоборот.

Ну дык Hashable extends Equatable или Hasher extends Equator и опять же имеем типизированную проверку этого факта.

vsb>> По-хорошему должны быть интерфейсы Equatable, Hashable, так же как Comparable и если нужны соотв. методы, реализуешь интерфейс. Либо, что ещё правильней, определять отдельные объекты вроде Equator, Hasher по аналогии с Comparator и передавать их в соотв. структуры данных.

N>Ну в плюсах есть такая возможность, но по умолчанию они используют таки стандартные сравнения.

А что такое стандартное сравнение для MyClass? operator== вроде не генерится автоматом, т.е. для обычного класса не определены ни сравнение ни хеширование.