История изменений

Или из (печального) опыта: если мы думаем «моделями», то если есть два объекта, их модели равны тогда, когда есть взаимооднозначное преобразование, превращающее одну модель в другую. С другой стороны, в Java строка типа if MyObject.getClass.isAssignableFrom(java.lang.System) всего лишь проверяет, что имя класса MyObject больше, чем имя «java.lang.System». Ну офигеть теперь. Это, конечно, хорошо, что мы уже научились сравнивать строки. Но в результате это приводит к такому пыщ-эффекту, что в Java во всех классах нужно вручную писать метод equals и hashCode, но по факту почти везде они либо не делают ничего, либо делают ересь (как раз по той причине, что их нужно писать везде и вручную, а людям работать надо, думать в таких объемах над философией некогда!). Т.е. в самом типичном коде прямоугольник с равными сторонами будет не equals квадрату, только потому, что имена типов разные. На этот счет есть свои кости и костыли (например, статья «как писать метод эквивалентности в Жабке» от атца Скалы, Одерски), но это ж капец. Я не уверен, что написание горы canEqual, hasEqual, shouldEqual, approxEqual итп есть правильная «таблица умножения», это скорее что-то типа задачи конем обойти шахматную доску и прийти в нужную точку. Как в анекдоте про специальную олимпиаду - даже если ты выиграл специальную олимпиаду, все равно ты инвалид.

Или из (печального) опыта: если мы думаем «моделями», то если есть два объекта, их модели равны тогда, когда есть взаимооднозначное преобразование, превращающее одну модель в другую. С другой стороны, в Java строка типа if MyObject.getClass.isAssignableFrom(java.lang.System) всего лишь проверяет, что имя класса MyObject больше, чем имя «java.lang.System». Ну офигеть теперь. Это, конечно, хорошо, что мы уже научились сравнивать строки :-) Что в результате приводит к такому пыщ-эффекту, что в Java во всех классах нужно вручную писать метод equals и hashCode, но по факту почти везде они либо не делают ничего, либо делают ересь. Т.е. в самом типичном коде прямоугольник с равными сторонами будет не equals квадрату, только потому, что имена типов разные. На этот счет есть свои кости и костыли (например, статья «как писать метод эквивалентности в Жабке» от атца Скалы, Одерски), но это ж капец. Я не уверен, что написание горы canEqual, hasEqual, shuldEqual, approxEqual итп есть правильная «таблица умножения», это скорее что-то типа задачи конем обойти шахматную доску и прийти в нужную точку. Как в анекдоте про специальную олимпиаду - даже если ты выиграл специальную олимпиаду, все равно ты инвалид.

Или из (печального) опыта: если мы думаем «моделями», то если есть два объекта, их модели равны тогда, когда есть взаимооднозначное преобразование, превращающее одну модель в другую. С другой стороны, в Java строка типа if MyObject.getClass.isAssignableFrom(java.lang.System) всего лишь проверяет, что имя класса MyObject больше, чем имя «java.lang.System». Что в результате приводит к такому пыщ-эффекту, что в Java во всех классах нужно вручную писать метод equals и hashCode, но по факту почти везде они либо не делают ничего, либо делают ересь. Т.е. в самом типичном коде прямоугольник с равными сторонами будет не equals квадрату, только потому, что имена типов разные. На этот счет есть свои кости и костыли (например, статья «как писать метод эквивалентности в Жабке» от атца Скалы, Одерски), но это ж капец. Я не уверен, что написание горы canEqual, hasEqual, shuldEqual, approxEqual итп есть правильная «таблица умножения», это скорее что-то типа задачи конем обойти шахматную доску и прийти в нужную точку. Как в анекдоте про специальную олимпиаду - даже если ты выиграл специальную олимпиаду, все равно ты инвалид.

Или из (печального) опыта: если мы думаем «моделями», то если есть два объекта, их модели равны тогда, когда есть взаимооднозначное преобразование, превращающее одну модель в другую. С другой стороны, в Java строка типа if MyObject.getClass.isAssignableFrom(java.lang.System) всего лишь проверяет, что имя класса MyObject больше, чем имя «java.lang.System». Что в результате приводит к такому пыщ-эффекту, что в Java во всех классах нужно вручную писать метод equals и hashCode, но по факту почти везде они либо не делают ничего, либо делают ересь. Т.е. в самом типичном коде прямоугольник с равными сторонами будет не equals квадрату, только потому, что имена типов разные. На этот счет есть свои кости и костыли (например, статья «как писать метод эквивалентности в Жабке» от атца Скалы, Одерски), но это ж капец. Я не уверен, что написание горы canEqual, hasEqual, shuldEqual, approxEqual итп есть правильная «таблица умножения», это скорее что-то типа задачи конем обойти шахматную доску и прийти в нужную точку.