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

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

ну с примитивами справилась

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

ну с примитивами справилась

в смысле?

в смысле?

примитивы вывел, а вот обекты уже нет

Не очень понимаю. Одинаковые примитивы?

а не я ошибку сделал

где тут примитивы:?

не знаю на сколько одинаковый случай

где тут примитивы:?

это уже вотрой вариант

Не очень понимаю. Одинаковые примитивы?

вместо A, B,C -> 1, 2, 3. Возращаемый тип был Int

Ну тогда тип везде одинаковый. В этом случае выводится

Базару ноль, это довольно странно. Возможно, просто различные версии котлина

да решение то понятно)

apply пробывал ?

apply пробывал ?

хотя мало погоды поменяет

Базару ноль, это довольно странно. Возможно, просто различные версии котлина

смамому интересно стало

Ну, я фиг знает. Mikhail @SchFuntik у вас какие версии котлина стоят?

у меня тоже пример выше вроде работает

Ну, я фиг знает. Mikhail @SchFuntik у вас какие версии котлина стоят?

1.2.51

1.2.30, но как сказал, пример выше тоже работает

у меня тоже пример выше вроде работает

просто не с андроида и не знаю про Fragment, может тебе в @kotlin_mobile, хотя народ +- один и тот же

может у тебя где то сапорт фрагмент а где то обычный

без алсо работает до сих, и фрагменты одинаковые

думаете особенность андроида?

думаете особенность андроида?

нет я думаю что где-то нет Fragment как родителя

дык без also всё работает и даже запускается

Да, теперь понятно. Вывод типов сейчас в Котлине происходит по отдельности для каждого вызова или встроенной конструкции. Т.е. тут сначала будет выводиться тип для when и только потом для also. И на этапе вывода типов для when компилятор не смог выбрать между I1/I2 (а без also там есть expected type I1, который подсказал) Мне кажется, это известная проблема, но если несложно, можешь, пожалуйста, отрепортить, раз уж минимизация уже есть? :)

не думаю что это баг, скорее вполне известное им "наш вывод типов пока недостаточно умён для этого"

на самом деле это фиксится не только отказом от also, но и введением общего типа который соберёт всех одинковых предков выводимых типов в один, и тогда снова всё чудесно выводится. Помнится на каком-то из докладов говорилось что у них там в внутри компилятора существуют толи union, толи intersection типы. По идее тут можно именно на стадии компиляции вводить типы пересечения которые потом бы кастовались к тому что нужно. Првада если там какая-нибудь сложная иерархия наследования, то не факт что помогло бы. Ну и да, этой мой дилетантский взгляд на проблему, я всё же ни разу не компиляторщик, и в исходниках котлина тоже не бывал :)

Добрый день, между вызовами особой разницы нету ? listener(name) listener.invoke(name) где var listener : (String) -> Unit

никакой разницы

второе наверное более читабельно

понял, спасибо

первый вариант - оператор для ключевого слова invoke

т.е. чисто синтаксический сахар

как по мне читабильнее первый

хм

значит каждому свое, просто заметил что в некоторых примерах люди пишут явно invoke, а я вызов функции писал сразу через скобки

второе наверное более читабельно

Только если ты из джавы пришел

вот и задумался

Только если ты из джавы пришел

оттуда )

но давно уже это было и не правда )

Это очевидно, нормальные люди (из скалы / C# / haskell / ...) не вызывают лямбды как интерфесы

(

а

ну ладно

)

Это очевидно, нормальные люди (из скалы / C# / haskell / ...) не вызывают лямбды как интерфесы

я из джавы, но вызываю функцию как функцию)

я тоже кстати ))

просто увидел примеры и задумался, как лучше

а так по наитию сразу вызывал сам через скобки и не думал про это )) как первое что в голову пришло )

просто увидел примеры и задумался, как лучше

На вкус и цвет. Делай как велит сердце )

ну тем не менее, смысла же нет invoke() лишний раз писать

выглядит как рудимент от джавовского callable интерфейса

ну тем не менее, смысла же нет invoke() лишний раз писать

"явное лучше неявного" )

только там выбора не было, а тут есть

Справедливости ради, лямбда может быть nullable. И тогда есть смысл в func?.invoke()

Справедливости ради, лямбда может быть nullable. И тогда есть смысл в func?.invoke()

Idea вроде сама поругает, если налабл вызвать как функцию.

"явное лучше неявного" )

Ох уж эти мантры джавистов. Может тебе и val "не явный", он же тип скрывает

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

Ох уж эти мантры джавистов. Может тебе и val "не явный", он же тип скрывает

Питонистов. От случая к случаю - иногда оно и правда мешает понять, что там. Но благо студия уже умеет добавлять тип в вывод.

не знаю в чём прикол не явных типов

Питонистов. От случая к случаю - иногда оно и правда мешает понять, что там. Но благо студия уже умеет добавлять тип в вывод.

TFW, говорят "студия умеет", хотя на самом деле "идея умеет" *sad frog.jpg*

ERROR: S client not available

он сразу у ArrayList'a например выводит List<>, а не ArrayList?

TFW, говорят "студия умеет", хотя на самом деле "идея умеет" *sad frog.jpg*

Idea могет больше, чем студия, ибо вторая опаздывает, поэтому отделяю.

он сразу у ArrayList'a например выводит List<>, а не ArrayList?

Нет, но можно явно указать, если нужно.

Idea могет больше, чем студия, ибо вторая опаздывает, поэтому отделяю.

Ну ладно тогда )

Нет, но можно явно указать, если нужно.

в общем не нужно в коллекциях лишь навредит

он сразу у ArrayList'a например выводит List<>, а не ArrayList?

Если тип не указан явно, пишет серым то, что язык выводит

Всем доброе утро! Подскажите есть ли у кого-нибудь набор примеров для KDoc? Что в какой ситуации нужно описывать, а что нет?

эээ. Убойный вопрос, но вообще хороший. Я думаю, что в качестве примера хорошо брать документацию kotlin

https://github.com/JetBrains/kotlin/blob/1.2.50/core/builtins/native/kotlin/Primitives.kt#L14

Больше этого не нужно, а то получится как в питоне. Я каждый раз страшно матерюсь, когда читаю питоновскую документацию.

эээ. Убойный вопрос, но вообще хороший. Я думаю, что в качестве примера хорошо брать документацию kotlin

хм, да, что-то про неё не подумал, просто почитал https://kotlinlang.org/docs/reference/kotlin-doc.html и пошел гуглить... Спасибо :)

эээ. Убойный вопрос, но вообще хороший. Я думаю, что в качестве примера хорошо брать документацию kotlin

Все public и protected. В интерфейсах — контракты, в классах — детали реализации.

Контракты - это немножко overkill наверное. Только для мощного проекта какого-нибудь

блин... ну как по мне вот это выглядит диковато /** Adds the other value to this value. */ public operator fun plus(other: Byte): Long /** Adds the other value to this value. */ public operator fun plus(other: Short): Long /** Adds the other value to this value. */ public operator fun plus(other: Int): Long /** Adds the other value to this value. */ public operator fun plus(other: Long): Long /** Adds the other value to this value. */ public operator fun plus(other: Float): Float /** Adds the other value to this value. */ public operator fun plus(other: Double): Double

Всем доброе утро! Подскажите есть ли у кого-нибудь набор примеров для KDoc? Что в какой ситуации нужно описывать, а что нет?

я вот как-то так делаю, см. файлы с этом каталоге https://github.com/Miha-x64/reactive-properties/tree/master/properties/src/main/kotlin/net/aquadc/properties

Да, но для релизной версии оно нужно

Именование файлов какое-то неортодоксальное

Именование файлов какое-то неортодоксальное

что не так и как надо?)

я вот как-то так делаю, см. файлы с этом каталоге https://github.com/Miha-x64/reactive-properties/tree/master/properties/src/main/kotlin/net/aquadc/properties

Не помнишь где там дата класс какой-нибудь лежит?

Я не говорю, что не так, я говорю, что не ортодоксально. Утил файлы с маленькой буквы. В этом что-то есть, но я такого еще не встречал. Дефисы в именах - это вообще что-то новое.

Нужно больше промышленных бизнес фасолин

Не помнишь где там дата класс какой-нибудь лежит?

никаких дата-классов в моём коде

Я не говорю, что не так, я говорю, что не ортодоксально. Утил файлы с маленькой буквы. В этом что-то есть, но я такого еще не встречал. Дефисы в именах - это вообще что-то новое.

с большой называю классы :) Дефисы — чтобы internal-классы были неюзабеьлны из джавушки. Кажется, мой пропозал на @JvmSynthetic для классов не оценили. https://youtrack.jetbrains.com/issue/KT-24981

А почему просто не обзвать их Internal

А почему просто не обзвать их Internal

ну, они, конечно, лежат в internal, но когда это кого останавливало?)

я про internal модификатор

Или ява его не видит?

я про internal модификатор

В яве это паблик

"явное лучше неявного" )

Это ж из питона

Это ж из питона

Да

Это ж из питона

это бест практис оф эни ленгвидж