да я проверяю именно !=0, но задался вопросом почему не могу сделать >

Ну потому, что для null логичным образом можно определить, эквивалентен он чему-то, или нет, а вот сравнить его на больше/меньше уже не получится. Может быть null > 0 или null < Int.MIN_VALUE ??

Если у нас для некоторого набора non null значений есть отношение порядка, то не понятно, как его расширить, чтобы оно null тоже включало. Это если математически про больше/меньше.

Ну потому, что для null логичным образом можно определить, эквивалентен он чему-то, или нет, а вот сравнить его на больше/меньше уже не получится. Может быть null > 0 или null < Int.MIN_VALUE ??

не уверен что null == 0 это выглядит логично, для меня это странная конструкция

не уверен что null == 0 это выглядит логично, для меня это странная конструкция

ну null это отсутствие объекта, 0 - объект, кажется весьма логичным

Если у нас для некоторого набора non null значений есть отношение порядка, то не понятно, как его расширить, чтобы оно null тоже включало. Это если математически про больше/меньше.

С NaN эту проблему решили, тем не менее)

А может кто-нибудь подсказать, есть ли аналог семафоров в котлиновских корутинах?

не уверен что null == 0 это выглядит логично, для меня это странная конструкция

В таком виде это странное выражение только потому, что оно очевидно равно false. Но фишка в том, что вместо null может быть другое значение val size: Int? = ... size == 0

ну null это отсутствие объекта, 0 - объект, кажется весьма логичным

в доке написано, что это автоматически трансформируется в a === null, то есть равенство ссылок, тогда это логично

из доки: "Заметьте, что в явном сравнении с null для оптимизации нет смысла: a == null будет автоматически транслироваться в a === null"

Добрый день! Помогите разобраться, пожалуйста, со следующим кодом. https://pastebin.com/VcG3SnQF Дело в том, что условия на строках 6 и 9 скомпилируются, а условие на 12 строке нет. Почему на 9 строке компилируется, а на 12 нет?

У вас в IDE будет детально написано

не уверен что null == 0 это выглядит логично, для меня это странная конструкция

Если у нас есть набор non null значений, для которых определено отношение эквивалентности, то приняв, что null эквивалентен только себе и ничему более, мы расширяем исходное отношение с тем, чтобы оно включало null.

Так что всё логично.

Добрый день! Помогите разобраться, пожалуйста, со следующим кодом. https://pastebin.com/VcG3SnQF Дело в том, что условия на строках 6 и 9 скомпилируются, а условие на 12 строке нет. Почему на 9 строке компилируется, а на 12 нет?

В youtrack хватает тикетов на подобные случаи, может, это один из них. Возможно, в 1.3 поведение будет ближе к ожидаемому (ничего не должно компилиться, компилятор вполне мог бы догадаться, что везде false).

В youtrack хватает тикетов на подобные случаи, может, это один из них. Возможно, в 1.3 поведение будет ближе к ожидаемому (ничего не должно компилиться, компилятор вполне мог бы догадаться, что везде false).

Ну по тому, что написано в kotlin.Any для equals, я бы ожидал, что всё должно скомпилиться.

Там написано, что всё со всем должно сравниваться на равенство.

Добрый день! Помогите разобраться, пожалуйста, со следующим кодом. https://pastebin.com/VcG3SnQF Дело в том, что условия на строках 6 и 9 скомпилируются, а условие на 12 строке нет. Почему на 9 строке компилируется, а на 12 нет?

В скобочки пробовали заключить операцию с as?

В скобочки пробовали заключить операцию с as?

Результат тот же

Добрый день! Помогите разобраться, пожалуйста, со следующим кодом. https://pastebin.com/VcG3SnQF Дело в том, что условия на строках 6 и 9 скомпилируются, а условие на 12 строке нет. Почему на 9 строке компилируется, а на 12 нет?

Как-то проифано в компиляторе, что при сравнении open классов и интерфейсов работает тупо Any.equals, а при сравнении значений final классов, компилятор проверяет что у них типы совпадают.

Зачем так - хз. Надо у создателей языка спрашивать. Почему это не задокументировано в Javadoc к Any.equals - тоже хз.

Странно. Жил с полной уверенностью, что у наллабл коллекций есть всякие методы аля isNullOrEmpty на манер строк. :(

Как-то проифано в компиляторе, что при сравнении open классов и интерфейсов работает тупо Any.equals, а при сравнении значений final классов, компилятор проверяет что у них типы совпадают.

Благодарю!

Ну по тому, что написано в kotlin.Any для equals, я бы ожидал, что всё должно скомпилиться.

Для equals в Any описан контракт, по которому такое сравнение не может дать true, учитывая реализацию equals у Enum. Реализация в SimpleClass, конечно, может вести себя иначе, но язык с safety в приоритете не должен позволять делать такое (в идеальном мире).

Куда/к кому можно обратиться за кодревью одного класса?

Зачем так - хз. Надо у создателей языка спрашивать. Почему это не задокументировано в Javadoc к Any.equals - тоже хз.

Проще/быстрее, вероятно. А не задокументировано, потому что может меняться с каждым релизом. И ломать кривой код - это вполне нормально, аналога JLS всё равно нет.

Кидай))

Котлиновского

На гист

https://gist.github.com/InsanusMokrassar/0720b26e2df7584e1121ba9df7aff7b9

Проще/быстрее, вероятно. А не задокументировано, потому что может меняться с каждым релизом. И ломать кривой код - это вполне нормально, аналога JLS всё равно нет.

Про JLS ошибся, есть https://github.com/JetBrains/kotlin-spec/blob/master/kotlin-spec.asc Но я там не вижу описания того, что можно сравнивать, а что нет.

Для equals в Any описан контракт, по которому такое сравнение не может дать true, учитывая реализацию equals у Enum. Реализация в SimpleClass, конечно, может вести себя иначе, но язык с safety в приоритете не должен позволять делать такое (в идеальном мире).

Kotlin - язык с Safety в приоритете? Ну ну. Язык с safety в приоритете не должен декларировать equals на уровне top типа в иерархии. Какой смысл имеет сравнение на равенство двух функций, например? Как вообще произвольные объекты сравнивать на равенство друг с другом? Это не имеет смысла => должен быть некий интерфейс, декларирующий, что его реализации можно сравнивать на равенство, по аналогии с Comparable для отношения порядка.

То, что сейчас творится с проифыванием в компиляторе - костыли поверх наследия, пришедшего из Java Object

Kotlin - язык с Safety в приоритете? Ну ну. Язык с safety в приоритете не должен декларировать equals на уровне top типа в иерархии. Какой смысл имеет сравнение на равенство двух функций, например? Как вообще произвольные объекты сравнивать на равенство друг с другом? Это не имеет смысла => должен быть некий интерфейс, декларирующий, что его реализации можно сравнивать на равенство, по аналогии с Comparable для отношения порядка.

Компромисс между нормальной системой типов и совместимостью с Java (и Java-разрабами). Наверняка думали об этом и отказались в итоге.

То, что сейчас творится с проифыванием в компиляторе - костыли поверх наследия, пришедшего из Java Object

Мне кажется, просто это не в приоритете, а в будущем будет покрываться куда больше случаев

Мне кажется, просто это не в приоритете, а в будущем будет покрываться куда больше случаев

Ну интересно посмотреть, как будет развиваться компилятор проверх кривого наследия, притянутого в систему типов. Мне кажется, то ещё зрелище будет.

Kotlin - язык с Safety в приоритете? Ну ну. Язык с safety в приоритете не должен декларировать equals на уровне top типа в иерархии. Какой смысл имеет сравнение на равенство двух функций, например? Как вообще произвольные объекты сравнивать на равенство друг с другом? Это не имеет смысла => должен быть некий интерфейс, декларирующий, что его реализации можно сравнивать на равенство, по аналогии с Comparable для отношения порядка.

интересно, почему этот интерфейс не сделали, звучит и правда сверхлогично

интересно, почему этот интерфейс не сделали, звучит и правда сверхлогично

Потому, что это пришло из Java, притом с тех времён, когда не было дженериков в Java

Кстати, приведённый пример в 1.3-RC работает так же, как раньше ?‍♂️ Ну, в другой раз

Потому, что это пришло из Java, притом с тех времён, когда не было дженериков в Java

так а что мешало в котлине сделать этот самый интерфейс?)

так а что мешало в котлине сделать этот самый интерфейс?)

А как классы, не реализующие этот интерфейс, в джаву отдавать?

так а что мешало в котлине сделать этот самый интерфейс?)

Заявленный 100% интероп, наверное) В ранних версиях например не было platform types, просто всё из Java считалось nullable. Но отказались от этого. Так же и здесь - как минимум было бы очень много боли при вызове Java-кода.

А как классы, не реализующие этот интерфейс, в джаву отдавать?

в java что хочешь с ними делать можно

в java что хочешь с ними делать можно

В том числе вызывать equals, который на них не определён?

так а что мешало в котлине сделать этот самый интерфейс?)

А как быть с Java объектами, при сравнении их в Kotlin? А что делать с Kotlin объектами, не реализующими интерфейс equals, когда ими пользуются из Java?

А как классы, не реализующие этот интерфейс, в джаву отдавать?

с equals по умолчанию

@antonkazakov вы не смотрели гист?

А как быть с Java объектами, при сравнении их в Kotlin? А что делать с Kotlin объектами, не реализующими интерфейс equals, когда ими пользуются из Java?

Java обьекты с переопределенным equals считать наследующими этот интерфейс

Было бы что-нибудь такое: Java: List<String> Kotlin: (Mutable)List<String!|Eq!>!|Eq!

Java обьекты с переопределенным equals считать наследующими этот интерфейс

Это уже Go напоминает. Реализовал методы - значит реализовал интерфейс.

Было бы что-нибудь такое: Java: List<String> Kotlin: (Mutable)List<String!|Eq!>!|Eq!

Плохой пример, надо заменить String на кастомный класс

мы ведь про интероп говорим

А как быть с Java объектами, при сравнении их в Kotlin? А что делать с Kotlin объектами, не реализующими интерфейс equals, когда ими пользуются из Java?

хм, ну да, ответа на первый вопрос у меня нет, но считать объекты из java наследниками по дефолту? на второй вопрос - используем дефолтный equals

Было бы что-нибудь такое: Java: List<String> Kotlin: (Mutable)List<String!|Eq!>!|Eq!

Выглядит мило и очевидно, особенно для языка, где нету ни типов-сумм, ни структурного полиморфизма (я понимаю, что речь исключительно о границе на интеропе, но всё же). Напомните, пожалуйста, какой профит?

Выглядит мило и очевидно, особенно для языка, где нету ни типов-сумм, ни структурного полиморфизма (я понимаю, что речь исключительно о границе на интеропе, но всё же). Напомните, пожалуйста, какой профит?

Невозможность вызвать equals/hashCode там, где он не имеет смысла. Но, видимо, это не такая горячая проблема в Java, чтобы так заморачиваться.

хм, ну да, ответа на первый вопрос у меня нет, но считать объекты из java наследниками по дефолту? на второй вопрос - используем дефолтный equals

А какой Equals<T> реализуют Java классы? Что вместо T в общем случае? Если предположить существование Equals интерфейса, он должен быть дженерик, как и Comparable.

Примерно интерфейс должен быть таким: interface Equals<T> { fun eq(other: T): Boolean fun hc(): Int } Вот где брать T для Java объектов - загадка.

Примерно интерфейс должен быть таким: interface Equals<T> { fun eq(other: T): Boolean fun hc(): Int } Вот где брать T для Java объектов - загадка.

В Java это Any?

https://gist.github.com/InsanusMokrassar/0720b26e2df7584e1121ba9df7aff7b9

Я вижу корутины и synchronized - наверняка они тебе там не нужны. Есть mutex, есть AtomicInteger

Я вижу корутины и synchronized - наверняка они тебе там не нужны. Есть mutex, есть AtomicInteger

Есть actor конечно же

https://gist.github.com/InsanusMokrassar/0720b26e2df7584e1121ba9df7aff7b9

семафору на каналах как бы делать надо

В Java это Any?

По факту - да, но тогда для всех Java объектов мы теряем type safety, декларированное интерфейсом. Опять всё со всем можно сравнивать, а тогда зачем нам интерфейс?

По факту - да, но тогда для всех Java объектов мы теряем type safety, декларированное интерфейсом. Опять всё со всем можно сравнивать, а тогда зачем нам интерфейс?

только для java созданных объектов

По факту - да, но тогда для всех Java объектов мы теряем type safety, декларированное интерфейсом. Опять всё со всем можно сравнивать, а тогда зачем нам интерфейс?

Всё как обычно: Java - это unsafe по определению. Безопасность только в котлиновском коде.

ERROR: S client not available

Потому и нет интерфейса, вместе него type safety для ==, прибитый костылями в компиляторе, там где получилось (для final классов)

семафору на каналах как бы делать надо

Ок, посмотрю, как на каналах его сделать

Была подобная мысль, но я пока что немного плаваю в терминологии и понимании того, как корутины на самом деле устроены

Всё как обычно: Java - это unsafe по определению. Безопасность только в котлиновском коде.

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

парни подскажите, никак не могу понять, как вот это val mySharedViewModel : MySharedViewModel by sharedViewModel() записать на джаве?

Потому и нет интерфейса, вместе него type safety для ==, прибитый костылями в компиляторе, там где получилось (для final классов)

Ну как прибитый... https://youtrack.jetbrains.com/issue/KT-22043 Сравнение енумов явно не самая сильная сторона kotlinc

парни подскажите, никак не могу понять, как вот это val mySharedViewModel : MySharedViewModel by sharedViewModel() записать на джаве?

А что возвращает sharedViewModel()?

kotlin.Lazy<T>

это koin

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

Ну допустим. А что с этим делать? var list = java.util.Collections.emptyList<Any>() list.add(1)

kotlin.Lazy<T>

Ну тогда private MySharedViewModel _mySharedViewModel = null; public MySharedViewModel getMySharedViewModel() { if(_mySharedViewModel == null) { _mySharedViewModel = sharedViewModel(); } return _mySharedViewModel; } (это топорный и не потокобезопасный вариант)

парни подскажите, никак не могу понять, как вот это val mySharedViewModel : MySharedViewModel by sharedViewModel() записать на джаве?

Шаг 1. Разобраться как работают https://kotlinlang.org/docs/reference/delegated-properties.html Шаг 2. Посмотреть на реализацию того что делает sharedViewModel Вот и все

Ну допустим. А что с этим делать? var list = java.util.Collections.emptyList<Any>() list.add(1)

Читать джавадоки, в которых указано, что все модифицирующие методы кидают исключения?

Как будто в котлине такой же код нельзя написать.

Читать джавадоки, в которых указано, что все модифицирующие методы кидают исключения?

То же самое можно сказать про nullability, только тут безопасностью и не пахнет.

Как будто в котлине такой же код нельзя написать.

Без участия Java-кода - нет

Здраствуйте, товарищи. Хочу заставить компилятор Kotlin (или IntelliJ) ругать меня за то, что я бросаю исключение, которое не указано в аннотации @Throws либо не ловлю исключение, которое бросает тот или иной метод. Короче говоря, хочу как в Java: получать по рукам за проверяемые исключения, которые не обрабатываются. Был ли у кого-то такой опыт? Я погуглил, внимательно посмотрел настройки Inspections в IntelliJ, но ничего не нашел.

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

зачем нулабельный?

Не-нуллабельный не боксится, если не присваивать его в Any/Number/etc

А можешь еще раз сказать, чего бы тебе хотелось? Обозначить в компайл-тайм, что у тебя тут JdbcConverter?

Да, или JdbcConverter & SqliteConverter, например

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

В Kotlin нету cheked эксепшнов, и @Throws нужен лишь для интеропа с джавой. В интренете можно найти кучу объяснений почему это так. Если по каким-то причинам хочется странного, можно посмотреть вот сюда https://arrow-kt.io/docs/patterns/error_handling/

В Kotlin нету cheked эксепшнов, и @Throws нужен лишь для интеропа с джавой. В интренете можно найти кучу объяснений почему это так. Если по каким-то причинам хочется странного, можно посмотреть вот сюда https://arrow-kt.io/docs/patterns/error_handling/

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

Таки релизнули: https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloads-5066655.html и http://jdk.java.net/11

Что, обновили лицензию (теперь все платно) ? укатываемся openjdk от redhat/azule

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

Да, так и есть

Страдает только кровавый ынтырпрайз

Да, или JdbcConverter & SqliteConverter, например

Есть джист? Мне кажется, что вариант дженерик в дженерике должен работать, но может я чего-то не знаю

Да, так и есть

Ну с oracle jdk большие проблемы с установкой, а в openjdk вроде не будет long-support вообще (только полу-годовые релизы).

Ну с oracle jdk большие проблемы с установкой, а в openjdk вроде не будет long-support вообще (только полу-годовые релизы).

Это у кого проблемы? У меня наоборот если что (Windows). Openjdk в виде зипа идет, для которого еще надо все пути прописывать.