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

разверни мыль пожалуйста, разве запроектированное в языке соглашение equals/hash не об этом?

Для хэшмапа есть как минимум три распространенных формы сравнения: identity, равенство ключей, и равенство всех пар ключ-значение. Если хэшмап упорядоченный, то может добавиться равенство порядка... а может и не добавляться. Из-за сложности объекта возникает более одного сравнения для одого и того же объекта.

Долго не буду мусолить, под барабанную дробь и взгляды замершей публики выдам великую тайну: сами данные редко меняются, чаще всего меняется способ их обработки в зависимости от контекста. Не просто «интерфейс», а именно способ обработки, вроде закрытия дескриптора в отдельных контекстах. Именно поэтому подход «присоединяем функции к неизменным данным» выигрывает у подхода «приводим объект к нужному типу». Приверженность второму, дефективному подходу приводит к необходимости впихнуть в класс невпихуемые функции и интерфейсы — чтобы описать все возможные и некоторые невозможные способы взаимодейтсвия с данными.

Зато этот тупиковый подход является хорошим оправданием для того, чтобы оставаться при работе, строгать метод за методом и интерфейс за интерфесом, получать гигантскую кучу взаимодублирующего кода, писать к ней такую же по объему документацию. Грубо говоря, для класса «собака» реализуем функции «почесать за ухом», «понюхать другую собаку», «пописать под кустом», «записаться в стрим» — короче говоря, формы взаимодействия С ДРУГИМИ ОБЪЕКТАМИ, что есть заранее невыполнимая до конца задача, потому что других объектов бесконечное число.

Да, стандартные интерфейсы немного облегчают задачу, но ровно пока тебе не придется решать минимально нестандратную задачу, которая не впишется в сотню заранее продуманных сценариев.

Кстати, за это же ненавижу Rust, только там кроме бесконечных специализированных функций есть еще нашествие ёлочек Option<Box<Vec<char>>>.

над экземплярам reference types можно провести identity test (бесполезный в нормальных задачах) и equality test. семантика последнего должна быть sane по-дефолту для встроенных в язык и библиотеку типов и определима программистом для его типов

Ты опять мыслишь в парадигме «класс должен уметь решать все на свете задачи». Как правило, сложный объект создают не для того, чтобы просто иметь ассоциативный массив строка-строка, там хранятся непростые ключи и непростые значения, которые могут по разному применяться в зависимости от того, какая функция с ними работает — именно потому нет никакого смысла раз и навсегда привязывать все функции к этому ассоциативному массиву. И когда ты это поймешь, то поймешь, что все эти сравнения сложных объектов должны реализовываться в ИСПОЛЬЗУЮЩЕМ хэшмап коде, а не в самом хэшмапе, реализацией либо явными функциями с говорящими названиями, либо прямо по месту инлайновым алгоритмом.

что еще важнее, оно работает в практических задачах, особенно если сравнивать с тем, где этого нет. поэтому нечто, над чем думали - оно лучше, по крайней мере для макаки типа меня.

Единственная «практическая задача», которую я тут вижу — это написать строки кода и пропорционально заработать деньги за них, в два раза больше строчек — в два раза больше денег. Красота.

Есть классная статья по этой теме, но для питона, там в том числе пример того, как код писателя строчек получилось ужать в 120 раз:
https://habr.com/articles/140581/

для эксперта типа тебя видимо жаву и жс уравнивает то, что ты вообще отбрасываешь из языка всё кроме возможности писать какой-то код и кроме его производительности. ну т.е. циклы крутит, условно переходит - ну и ок

Решает задачи пользователя. Больше меня ничего не колышет.

разверни мыль пожалуйста, разве запроектированное в языке соглашение equals/hash не об этом?

Для хэшмапа есть как минимум три распространенных формы сравнения: identity, равенство ключей, и равенство всех пар ключ-значение. Если хэшмап упорядоченный, то может добавиться равенство порядка... а может и не добавляться. Из-за сложности объекта возникает более одного сравнения для одого и того же объекта.

Долго не буду мусолить, под барабанную дробь и взгляды замершей публики выдам великую тайну: сами данные редко меняются, чаще всего меняется способ их обработки в зависимости от контекста. Не просто «интерфейс», а именно способ обработки, вроде закрытия дескриптора в отдельных контекстах. Именно поэтому подход «присоединяем функции к неизменным данным» выигрывает у подхода «приводим объект к нужному типу». Приверженность второму, дефективному подходу приводит к необходимости впихнуть в класс невпихуемые функции и интерфейсы — чтобы описать все возможные и некоторые невозможные способы взаимодейтсвия с данными.

Зато этот тупиковый подход является хорошим оправданием для того, чтобы оставаться при работе, строгать метод за методом и интерфейс за интерфесом, получать гигантскую кучу взаимодублирующего кода, писать к ней такую же по объему документацию. Грубо говоря, для класса «собака» реализуем функции «почесать за ухом», «понюхать другую собаку», «пописать под кустом», «записаться в стрим» — короче говоря, формы взаимодействия С ДРУГИМИ ОБЪЕКТАМИ, что есть заранее невыполнимая до конца задача, потому что других объектов бесконечное число.

Да, стандартные интерфейсы немного облегчают задачу, но ровно пока тебе не придется решать минимально нестандратную задачу, которая не впишется в сотню заранее продуманных сценариев.

Кстати, за это же ненавижу Rust, только там кроме бесконечных специализированных функций есть еще нашествие ёлочек Option<Box<Vec<char>>>.

над экземплярам reference types можно провести identity test (бесполезный в нормальных задачах) и equality test. семантика последнего должна быть sane по-дефолту для встроенных в язык и библиотеку типов и определима программистом для его типов

Ты опять мыслишь в парадигме «класс должен уметь решать все на свете задачи». Как правило, сложный объект создают не для того, чтобы просто иметь ассоциативный массив строка-строка, там хранятся непростые ключи и непростые значения, которые могут по разному применяться в зависимости от того, какая функция с ними работает — именно потому нет никакого смысла раз и навсегда привязывать все функции к этому ассоциативному массиву. И когда ты это поймешь, то поймешь, что все эти сравнения сложных объектов должны реализовываться в ИСПОЛЬЗУЮЩЕМ хэшмап коде, либо явными функциями с говорящими названиями, либо прямо по месту инлайновым алгоритмом.

что еще важнее, оно работает в практических задачах, особенно если сравнивать с тем, где этого нет. поэтому нечто, над чем думали - оно лучше, по крайней мере для макаки типа меня.

Единственная «практическая задача», которую я тут вижу — это написать строки кода и пропорционально заработать деньги за них, в два раза больше строчек — в два раза больше денег. Красота.

Есть классная статья по этой теме, но для питона, там в том числе пример того, как код писателя строчек получилось ужать в 120 раз:
https://habr.com/articles/140581/

для эксперта типа тебя видимо жаву и жс уравнивает то, что ты вообще отбрасываешь из языка всё кроме возможности писать какой-то код и кроме его производительности. ну т.е. циклы крутит, условно переходит - ну и ок

Решает задачи пользователя. Больше меня ничего не колышет.

разверни мыль пожалуйста, разве запроектированное в языке соглашение equals/hash не об этом?

Для хэшмапа есть как минимум три распространенных формы сравнения: identity, равенство ключей, и равенство всех пар ключ-значение. Если хэшмап упорядоченный, то может добавиться равенство порядка... а может и не добавляться. Из-за сложности объекта возникает более одного сравнения для одого и того же объекта.

Долго не буду мусолить, под барабанную дробь и взгляды замершей публики выдам великую тайну: сами данные редко меняются, чаще всего меняется способ их обработки в зависимости от контекста. Не просто «интерфейс», а именно способ обработки, вроде закрытия дескриптора в отдельных контекстах. Именно поэтому подход «присоединяем функции к неизменным данным» выигрывает у подхода «приводим объект к нужному типу». Приверженность второму, дефективному подходу приводит к необходимости впихнуть в класс невпихуемые функции и интерфейсы — чтобы описать все возможные и некоторые невозможные способы взаимодейтсвия с данными.

Зато этот тупиковый подход является хорошим оправданием для того, чтобы оставаться при работе, строгать метод за методом и интерфейс за интерфесом, получать гигантскую кучу взаимодублирующего кода, писать к ней такую же по объему документацию. Грубо говоря, для класса «собака» реализуем функции «почесать за ухом», «понюхать другую собаку», «пописать под кустом», «записаться в стрим» — короче говоря, формы взаимодействия С ДРУГИМИ ОБЪЕКТАМИ, что есть заранее невыполнимая до конца задача, потому что других объектов бесконечное число.

Да, стандартные интерфейсы немного облегчают задачу, но ровно пока тебе не придется решать минимально нестандратную задачу, которая не впишется в сотню заранее продуманных сценариев.

Кстати, за это же ненавижу Rust, только там кроме бесконечных специализированных функций есть еще нашествие ёлочек Option<Box<Vec<char>>>.

над экземплярам reference types можно провести identity test (бесполезный в нормальных задачах) и equality test. семантика последнего должна быть sane по-дефолту для встроенных в язык и библиотеку типов и определима программистом для его типов

Ты опять мыслишь в парадигме «класс должен уметь решать все на свете задачи». Как правило, сложный объект создают не для того, чтобы просто иметь ассоциативный массив строка-строка, там хранятся непростые ключи и непростые значения, которые могут по разному применяться в зависимости от того, какая функция с ними работает — именно потому нет никакого смысла раз и навсегда привязывать все функции к этому ассоциативному массиву. И когда ты это поймешь, то поймешь, что все эти сравнения сложных объектов должны реализовываться в хэшмап коде, либо явными функциями с говорящими названиями, либо прямо по месту инлайновым алгоритмом.

что еще важнее, оно работает в практических задачах, особенно если сравнивать с тем, где этого нет. поэтому нечто, над чем думали - оно лучше, по крайней мере для макаки типа меня.

Единственная «практическая задача», которую я тут вижу — это написать строки кода и пропорционально заработать деньги за них, в два раза больше строчек — в два раза больше денег. Красота.

Есть классная статья по этой теме, но для питона, там в том числе пример того, как код писателя строчек получилось ужать в 120 раз:
https://habr.com/articles/140581/

для эксперта типа тебя видимо жаву и жс уравнивает то, что ты вообще отбрасываешь из языка всё кроме возможности писать какой-то код и кроме его производительности. ну т.е. циклы крутит, условно переходит - ну и ок

Решает задачи пользователя. Больше меня ничего не колышет.