Всем привет. Поясните, плиз, почему я могу сравнить две строки: var s1 = "aaab" var s2 = "aaaa" var b = s1 < s2 но не могу два data-класса, хранящих строки? data class StrData(var data : String) var r1 = StrData("vsya") var r2 = StrData( "vsyb") var bb = r2 < r1

Потому что в Kotlin String наследует Comparable<String> а произвольный дата класс-нет. Но всегда можно написать оператор.

Дата-классам не генерируется оператор проверки на меньше?

Дата-классам не генерируется оператор проверки на меньше?

Нет. Нет никакой гарантии, что никакое из полей дата-класса не содержит не-Comparable.

Ээ... То же самое можно сказать и про equality.

Ээ... То же самое можно сказать и про equality.

Нет, equals определён в Any.

Ясно, спасибо.

Ээ... То же самое можно сказать и про equality.

Ты откуда такой? Java вообще что-ли в глаза не видел?

Видел, я знаю, что оно умеет сравниваться по адресам по-умолчанию.

Просто не считаю это правильным поведением для data-классов.

Просто не считаю это правильным поведением для data-классов.

каким образом можно автоматически реализовать компейр?

Зачем реализовывать его заведомо неправильным способом для 80% случаев?

Зачем реализовывать его заведомо неправильным способом для 80% случаев?

кого?

Компейр.

Компейр.

Так поэтому и не реализовывает.

А. Сорри, я про equal.

Если дата-класс содаржит примитивы, строки и дата-классы, то всё правильно.

Видел, я знаю, что оно умеет сравниваться по адресам по-умолчанию.

У тебя есть два реальных варианта (и даже IDEA сама предлагает их) 1) data class StrData(var data: String) { operator fun compareTo(other: StrData): Int = data.compareTo(other.data) } 2) operator fun StrData.compareTo(other: Example8.StrData): Int = data.compareTo(other.data)

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

У тебя есть два реальных варианта (и даже IDEA сама предлагает их) 1) data class StrData(var data: String) { operator fun compareTo(other: StrData): Int = data.compareTo(other.data) } 2) operator fun StrData.compareTo(other: Example8.StrData): Int = data.compareTo(other.data)

Да, я в курсе.

Я хочу, чтоб это делал сам язык.

Увы.

Я хочу, чтоб это делал сам язык.

Расскажи мне как он это сделает для? data class StrData(var data: Thread) Или для дву и более полей (из которых половина nullable) data class StrData(var data: String, val value: Int?)

Я хочу, чтоб это делал сам язык.

Если все свойства Comparable, в каком порядке их сравнивать?

https://youtrack.jetbrains.com/issue/KT-8466

Если все свойства Comparable, в каком порядке их сравнивать?

Очевидно, в порядке перечисления.

Расскажи мне как он это сделает для? data class StrData(var data: Thread) Или для дву и более полей (из которых половина nullable) data class StrData(var data: String, val value: Int?)

Это стоит делать для тех классов, где все элементы предоставляют такие методы.

Очевидно, в порядке перечисления.

не очевидно лол

очень не очевидно

А как ещё?

ну сам подумай

поменялась у тебя логика

теперь нужно компейр делать в другом порядке

Описываешь его ручками.

что делать в таком случае? переопределять или менять/добавлять конструктор

ну вот видимо решили такую путаницу не делать

Но уметь как-то сортировать элементы по-умолчанию было бы неплохо.

Но уметь как-то сортировать элементы по-умолчанию было бы неплохо.

«как-то» — плохо. Философия Котлина — всё должно быть явно и очевидно.

Как-то - не значит не очевидно.

Это стоит делать для тех классов, где все элементы предоставляют такие методы.

Делать не фичу, которая работает в половине случае и каком-то узком кейсе - полный бред и никто это делать не будет. Тебе дали возможности расширения - вот ими и пользуйся.

Делать не фичу, которая работает в половине случае и каком-то узком кейсе - полный бред и никто это делать не будет. Тебе дали возможности расширения - вот ими и пользуйся.

Я хочу писать меньше кода там, где он уже написан.

В моём понимании существование equals и отсутствие compare - полный бред.

compare прямо в объекте - полный бред

хочешь сравнивать - пиши компоратор

или заветы effective java забыты?

compare прямо в объекте - полный бред

О, хороший поинт. Я то же самое думаю и про equals.

преставь такой кейс: автор библиотеки предоставляет data class, где все поля Comparable, компилятор генерирует метод compareTo

ты на это закладываешься и радуешься жизни

в следующей версии библиотеки автор доавбялет новое поле с дефолтным значеним (для обратной совместимости)

но тип уже не Comparable

В моём понимании существование equals и отсутствие compare - полный бред.

Не тупи, братишь, equals там унаследован от java.lang.Object (как и wait/toString) https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#equals(java.lang.Object)

метод compareTo пропадает

твой код ломается

метод compareTo пропадает

ну, это сламывание совместимости автором

твой код ломается

и это тоже хороший поинт

О, хороший поинт. Я то же самое думаю и про equals.

Думаешь equals/toString/wait/hashCode не нужны в базовых классах?

это будет означать что автор библиотеки на каждый data class должен писать тест

что он comparable

ну, это сламывание совместимости автором

но если это делается under the hood то автор мог и не заметить

Думаешь equals/toString/wait/hashCode не нужны в базовых классах?

Я думаю, что реализация equals через сравнение указателей для data-классов - бессмысленна.

О, хороший поинт. Я то же самое думаю и про equals.

потому что композиция?)

потому что композиция?)

Нет, потому что объекты могут быть «равны» по-разному, в разном смысле, для разных целей.

Нет, потому что объекты могут быть «равны» по-разному, в разном смысле, для разных целей.

А как ты предлагаешь работать функциям сортировки и тд? Везде явно передать лямбду или comparable? (или может быть через имплиситы…)

А как ты предлагаешь работать функциям сортировки и тд? Везде явно передать лямбду или comparable? (или может быть через имплиситы…)

Передавать явно, как компаратор в TreeMap.

Из-за того что кому-то может понадобиться два критерия равенства все должны явно его передавать.

Так себе.

Ну, вообще очевидного равенства или очевидного сравнения почти никогда не бывает. Полагаться на порядок полей в описании - это полный ужас.

Передавать явно, как компаратор в TreeMap.

А что думаешь про toString?

ERROR: S client not available

А что думаешь про toString?

норм, это чисто дебажная штука

А что думаешь про toString?

То же самое же - для разных мест разный toString

Как это дебажный? Я может хочу в console logger делать человеко понятный toString, а в file logger - json-like

нужно тоже передавать реализацию конкретную везде

Ну, тогда пиши разные методы и передавай их явно. А стандартный toString - для дебага )

Но вообще не хватает хитрых средств обеспечения code style. Типа, если в code style есть стандарт на наличие в каждом классе домена двух вариантов toString, то как проверить это при сборке проекта? Аналогично - если у меня запрещено использовать встроенные синглтоны или глобальные переменные - то тоже хочется это проверять на этапе сборки проекта, а не через code review )

Но вообще не хватает хитрых средств обеспечения code style. Типа, если в code style есть стандарт на наличие в каждом классе домена двух вариантов toString, то как проверить это при сборке проекта? Аналогично - если у меня запрещено использовать встроенные синглтоны или глобальные переменные - то тоже хочется это проверять на этапе сборки проекта, а не через code review )

Статические анализаторы должны помочь. Два варианта toString — объяви интерфейс для этого.

Статические анализаторы под такие задачи не настроишь ( Это скорее отдельный инструмент, заточенный именно под kotlin и интегрированный с Idea. Но если что-то из этого уже есть - то буду рад ) Интерфейс - оно понятно, но как гарантировать, что все созданные в проекте классы его реализуют )

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

Этим путем шли многие языки, результат плачевный. Из прекрасного в истории - в некоторых языках переменные i,j,k всегда были только integer, они же обычно используются в циклах )

Но вообще универсального решения для сравнения вообще не бывает.

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

Ну как тебе сказать, есть таки способы делать универсально, но при это не “передавая реализацию явно” ? (может и в Котлин завезут когда-нибудь)

Ну как тебе сказать, есть таки способы делать универсально, но при это не “передавая реализацию явно” ? (может и в Котлин завезут когда-нибудь)

Как это могло бы выглядеть?

Как мне кажется, идея смотреть на элементы data-класса, и предоставлять реализацию compare, когда в каждом из них он определён - скорее полезная вещь, чем нет. Мы ведь ни в чём при этом не ограничиваем пользователя класса.

Ну как тебе сказать, есть таки способы делать универсально, но при это не “передавая реализацию явно” ? (может и в Котлин завезут когда-нибудь)

Это опасная дорожка

Нет, потому что объекты могут быть «равны» по-разному, в разном смысле, для разных целей.

чито?

Как мне кажется, идея смотреть на элементы data-класса, и предоставлять реализацию compare, когда в каждом из них он определён - скорее полезная вещь, чем нет. Мы ведь ни в чём при этом не ограничиваем пользователя класса.

Скорее вредная. Полезная — сделать это явно. Например, реализовывать Comparable если он есть в списке надтипов (data class X : Comparable<X>).

чито?

равны ID; равно содержание; равны контекстно-зависимые метаданные

Скорее вредная. Полезная — сделать это явно. Например, реализовывать Comparable если он есть в списке надтипов (data class X : Comparable<X>).

Я не совсем уверен, но это скорее относится к аспекту реализации, с точки зрения пользователя класса это будет выглядеть просто как наличествующая функция сравнения, нет?

Я не совсем уверен, но это скорее относится к аспекту реализации, с точки зрения пользователя класса это будет выглядеть просто как наличествующая функция сравнения, нет?

Это крайне важный аспект реализации. Явность.

равны ID; равно содержание; равны контекстно-зависимые метаданные

одно одинаковое поле в объектах - не делает объекты равными(если у них не одно поле) вот если бизнеслогика требует то это явно не коммон кейс и скорее ломания "правильной" реализации сравнения

Это крайне важный аспект реализации. Явность.

При этом нужно будет самому описывать реализацию сравнения?

одно одинаковое поле в объектах - не делает объекты равными(если у них не одно поле) вот если бизнеслогика требует то это явно не коммон кейс и скорее ломания "правильной" реализации сравнения

Допустим, в одном сете я хочу держать записи с уникальными ID, в другом — записи с уникальным содержимым. Всё, только обёртками обмазываться.

При этом нужно будет самому описывать реализацию сравнения?

Я сейчас не про реализацию руками говорю, с ней всё понятно.

Допустим, в одном сете я хочу держать записи с уникальными ID, в другом — записи с уникальным содержимым. Всё, только обёртками обмазываться.

я больше о самой концепции объекта говорю, понятно что есть кейсы где все нужно

я больше о самой концепции объекта говорю, понятно что есть кейсы где все нужно

Нужны ли hashCode и equals сферическому объекту в вакууме?

Нужны ли hashCode и equals сферическому объекту в вакууме?

да, потому что стандартные коллекции с ними работают

да, потому что стандартные коллекции с ними работают

Нужно ли разрешать действия, которые требуют сравнения, над объектами, которые не умеют сравнивать?

поспешил) сферическому не нужны

нашему - нужны

Нужно ли разрешать действия, которые требуют сравнения, над объектами, которые не умеют сравнивать?

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

от этого и едем дальше