Size: a a a

Kotlin Community

2020 March 30

AM

Andrew Mikhaylov in Kotlin Community
Vladimir Petrakovich
Да, точно, так работает
Тогда снова непонятно, зачем она
Это был временный костыль до введения модификатора suspend для лямбд, чтобы не ломать бинарную совместимость. Со временем её обещали депрекейтнуть.
источник

VP

Vladimir Petrakovich in Kotlin Community
Andrew Mikhaylov
Это был временный костыль до введения модификатора suspend для лямбд, чтобы не ломать бинарную совместимость. Со временем её обещали депрекейтнуть.
Тогда странно, что оно не deprecated с 1.3 🤔
источник

AM

Andrew Mikhaylov in Kotlin Community
Vladimir Petrakovich
Тогда странно, что оно не deprecated с 1.3 🤔
Можно при желании поискать таску на ютреке.
источник

AO

Alexey Otts in Kotlin Community
Vladimir Petrakovich
Да, точно, так работает
Тогда снова непонятно, зачем она
Чтобы тип не писать 🤷
источник

VV

Vladislav Verminsky in Kotlin Community
Всем, привет!
Вот на код ревью написал, что использовать ! как отрицание не очень идеоматично, в котлине есть функция not(), которая улучшает читаемость кода, так как заметнее и имеет оптимизации на уровне компилятора, который превратит это в обычное отрицание чтобы не делать вызов метода.
Мне в ответ сказали, что это дичь и где я такое взял.
Вот теперь гуглю и не могу найти, где это обсуждалась и на каких исследованиях доказывалось.
Можете помочь найти правоту моих слов или я не прав?
источник

AL

Alexander Levin in Kotlin Community
Vladislav Verminsky
Всем, привет!
Вот на код ревью написал, что использовать ! как отрицание не очень идеоматично, в котлине есть функция not(), которая улучшает читаемость кода, так как заметнее и имеет оптимизации на уровне компилятора, который превратит это в обычное отрицание чтобы не делать вызов метода.
Мне в ответ сказали, что это дичь и где я такое взял.
Вот теперь гуглю и не могу найти, где это обсуждалась и на каких исследованиях доказывалось.
Можете помочь найти правоту моих слов или я не прав?
not - это operator fun, т.е. ожидается, что скорее всего будет использоваться !. Так что скорее вы совсем не правы :)

Из косвенных моментов я бы ещё вспомнил, что вряд ли бы делали встроенные в языке операторы !in и !is если бы не ожидали использования просто ! :)
источник

AN

Alexander Nozik in Kotlin Community
Vladislav Verminsky
Всем, привет!
Вот на код ревью написал, что использовать ! как отрицание не очень идеоматично, в котлине есть функция not(), которая улучшает читаемость кода, так как заметнее и имеет оптимизации на уровне компилятора, который превратит это в обычное отрицание чтобы не делать вызов метода.
Мне в ответ сказали, что это дичь и где я такое взял.
Вот теперь гуглю и не могу найти, где это обсуждалась и на каких исследованиях доказывалось.
Можете помочь найти правоту моих слов или я не прав?
Я бы сказал, что not - дейсвтительно дичь. Есть библиотечные функции типа isNotNull. Вот их рекомендуется использовать вместо !isNull
источник

MK

Mark Kos in Kotlin Community
В тему operator fun.
operator fun invoke иногда довольно красивая штука (когда класс аля команда).  В нашем проекте отказались от использования, так как ломается навигация по коду (навигироваться можно только ткнув на скобочку). Может есть/планируется улучшение навигации в идее для этой фичи?
источник

AN

Alexander Nozik in Kotlin Community
Mark Kos
В тему operator fun.
operator fun invoke иногда довольно красивая штука (когда класс аля команда).  В нашем проекте отказались от использования, так как ломается навигация по коду (навигироваться можно только ткнув на скобочку). Может есть/планируется улучшение навигации в идее для этой фичи?
Я думаю, что навигация в смысле invoke - это последняя проблема. Там можно получить довольно неочевидные поведения. Следует ограничить использование этой возможности теми случаями, когда очевидно, что она делает и навигация не нужна.
источник

AN

Alexander Nozik in Kotlin Community
Аргумет о том, что сложно ткнуть в скобочку мне кажется сильно надуманным.
источник

MK

Mark Kos in Kotlin Community
Alexander Nozik
Я думаю, что навигация в смысле invoke - это последняя проблема. Там можно получить довольно неочевидные поведения. Следует ограничить использование этой возможности теми случаями, когда очевидно, что она делает и навигация не нужна.
Можно почитать где-то про эти проблемы?
источник

MK

Mark Kos in Kotlin Community
Alexander Nozik
Аргумет о том, что сложно ткнуть в скобочку мне кажется сильно надуманным.
ну для нас польза от invoke - выглядит красиво. Так что недостаток неудобно ходить внутрь  такой же надуманный как и преемущество.
источник

AN

Alexander Nozik in Kotlin Community
Mark Kos
Можно почитать где-то про эти проблемы?
Ну проблемы довольно очевидные. Если вы навешиваете этот метод на какой-то тип, который не очевидно что делает, вы получаете неочевидные лексические конструкции
источник

AN

Alexander Nozik in Kotlin Community
Mark Kos
ну для нас польза от invoke - выглядит красиво. Так что недостаток неудобно ходить внутрь  такой же надуманный как и преемущество.
А пример использования?
источник

AN

Alexander Nozik in Kotlin Community
Я знаю всего два места, где это опрвдано - функциеподобные объекты, которые действительно можно вызвать или фальшивый конструктор через Invoke компаньена
источник

AO

Alexey Otts in Kotlin Community
Alexander Nozik
Я думаю, что навигация в смысле invoke - это последняя проблема. Там можно получить довольно неочевидные поведения. Следует ограничить использование этой возможности теми случаями, когда очевидно, что она делает и навигация не нужна.
ретроградство какое то
источник

AN

Alexander Nozik in Kotlin Community
В редких случаях в билдерах оправдано
источник

MK

Mark Kos in Kotlin Community
Есть фреймоворк для оркестрации саги, работает на аспектах. Каждый вызов в другую систему нужно оборачивать в специальный класс (чтоб вести лог вызовов). По сути сам класс содержит переадресацию в смежника и метод отката вызова. В итоге есть классы аля ReserveSomeShitStep с одним публичным методом
источник

AN

Alexander Nozik in Kotlin Community
Mark Kos
Есть фреймоворк для оркестрации саги, работает на аспектах. Каждый вызов в другую систему нужно оборачивать в специальный класс (чтоб вести лог вызовов). По сути сам класс содержит переадресацию в смежника и метод отката вызова. В итоге есть классы аля ReserveSomeShitStep с одним публичным методом
Ну так тут очевидно, что он делает. Это де-факто функциональный интерфейс
источник

MK

Mark Kos in Kotlin Community
Ага
источник