А, ну да

ЧО, ПАЦАНЫ, КОГДА ТАМ KOTLIN NATIVE ЗАРЕЛИЗИТСЯ?

Что там есть такого из фич, что есть в котлине, например

Кстати главная фича 2.0 - там убрали new оператор. Прям как в Котлине ?

Что там есть такого из фич, что есть в котлине, например

Интереснее то, что там есть, чего в котлине нет?

Интереснее то, что там есть, чего в котлине нет?

оператор cascade, mixins

Интереснее то, что там есть, чего в котлине нет?

Кроссплатформенный UI на мобилках ?‍♀

кстати, а значок пайпа |> случаем не из F#?

кстати, а значок пайпа |> случаем не из F#?

Скорее всего окамла, а может ещё раньше был

оператор cascade, mixins

Ок, надо будет глянуть

кажется, там (в F#) приоритет оператора определяется по первому символу значка

Ок, надо будет глянуть

ну и dynamic упоминали выше

Кроссплатформенный UI на мобилках ?‍♀

Ну это уже относится не к языку

Ну это уже относится не к языку

Ну это всё-таки относится к технологическому стеку и влияет на выбор языка ?

оператор cascade, mixins

лол, так cascade это же apply

лол, так cascade это же apply

Удобнее писать

+ не возникает проблем с выведением типов

а какие проблемы у apply?

Да тут выше как-то раз была история

Ну это всё-таки относится к технологическому стеку и влияет на выбор языка ?

Согласен, но то, что Google планирует построить новый UI-фреймворк или ОС на нём, не делает его автоматически хорошим, удобным или подходящим для этого.

Согласен, но то, что Google планирует построить новый UI-фреймворк или ОС на нём, не делает его автоматически хорошим, удобным или подходящим для этого.

Народу флаттер нравится ¯\_(ツ)_/¯ А выбирать другой язык к этому фреймворку не выйдет. Каждому своё же.

а какие проблемы у apply?

fun getFragment(state: Int): Fragment = when (state) { 1 -> Type1Fragment() 2 -> Type2Fragment() else -> Type3Fragment() }.apply { /* log */ } Компилятор не мог вывести Fragment, выводил Any

fun getFragment(state: Int): Fragment = when (state) { 1 -> Type1Fragment() 2 -> Type2Fragment() else -> Type3Fragment() }.apply { /* log */ } Компилятор не мог вывести Fragment, выводил Any

а без apply все ок?

а без apply все ок?

Да

В оригинале вообще был also, но у них все равно контракт почти одинаковый

а что в логе?

ну also так-то поидиоматичнее тут будет, если только логирование, да

*полез в REPL*

Да в логе ничего особенного, просто что-то вроде Timber.i("chosen fragment is: %s", it.toString()) Смысл в том только, что без экстеншена он тип нормально вывел, а с экстеншеном - нет

то же самое, например, если пишешь nullableMap ?: HashMap().also { nullableMap = it }

то же самое, например, если пишешь nullableMap ?: HashMap().also { nullableMap = it }

Какая-то монструозная конструкция

знать бы, чем заменить её

знать бы, чем заменить её

lazy не зайдёт?

lazy не зайдёт?

не, наоборот, хочу не выделять объект, пока не нужен

то же самое, например, если пишешь nullableMap ?: HashMap().also { nullableMap = it }

если дело в интеропе замени HashMap на mutableMap(), должно получиться

*А какой тип выводит компилятор в идее для it в println(it)?

*А какой тип выводит компилятор в идее для it в println(it)?

Вероятно, A

В общем, в тот раз все закончилось именно тем, что никто так и не разобрался, почему оно ломалось

Но может быть из-за интеропа с джавой, да

если дело в интеропе замени HashMap на mutableMap(), должно получиться

причём тут интероп и почему для mutableMap должно нормально вывестись?

*А какой тип выводит компилятор в идее для it в println(it)?

A

причём тут интероп и почему для mutableMap должно нормально вывестись?

Разобрался, у тебя другой случай https://github.com/Kotlin/KEEP/pull/35

Разобрался, у тебя другой случай https://github.com/Kotlin/KEEP/pull/35

это точно не мой случай

ещё 1 вопрос, а вот как мне при top-level functions, найти все методы которые описаны в 1 файле получается, ну в Java я мог дёрнуть класс и посмотреть, а здесь как?

ещё 1 вопрос, а вот как мне при top-level functions, найти все методы которые описаны в 1 файле получается, ну в Java я мог дёрнуть класс и посмотреть, а здесь как?

из Java можно так же — дёрнуть класс и посмотреть

а из котлина как?

из Java то понятно...

можно, конечно, Class.forName...

можно, конечно, Class.forName...

блин..как то стремно... а другой нету возможности? :-(

Опять?

ещё 1 вопрос, а вот как мне при top-level functions, найти все методы которые описаны в 1 файле получается, ну в Java я мог дёрнуть класс и посмотреть, а здесь как?

В каком смысле найти? В рантайме через reflection?

В каком смысле найти? В рантайме через reflection?

Я так понимаю речь про интелисенс

ещё 1 вопрос, а вот как мне при top-level functions, найти все методы которые описаны в 1 файле получается, ну в Java я мог дёрнуть класс и посмотреть, а здесь как?

ну имя файла вводишь и тыкаешь

Если файл называется Foo.kt, то из джавки он выглядит как класс FooKt

ну имя файла вводишь и тыкаешь

ну это ж.. плохо, если таки классов будет много... то запутаться как нефиг нафиг

просто в Java стильные классы они как разграничиваются по зоне ответственности

тут все в 1 куче будет и концов не соберёшь

а, то есть вопрос не про рефлекшен?)

а, то есть вопрос не про рефлекшен?)

не не :-)

возможно криво задал

просто в Java стильные классы они как разграничиваются по зоне ответственности

Для ограничения скоупа - компаньоны :)

Для ограничения скоупа - компаньоны :)

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

по этому немного скептически отношусь

если есть интересные примеры кто так уже писал.... можете скинуть?

типо open source на котлине

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

* процедурный

ERROR: S client not available

по этому немного скептически отношусь

У тебя есть варианты как это организовать. Выбирай подходящий и все будет хорошо :)

* процедурный

сори, ты прав

если есть интересные примеры кто так уже писал.... можете скинуть?

ну типа вот https://github.com/Miha-x64/reactive-properties/blob/master/properties/src/main/kotlin/net/aquadc/properties/inlineExtensions.kt

ну тут экстешен, а если я не могу применить ее как экстешен

У тебя есть варианты как это организовать. Выбирай подходящий и все будет хорошо :)

а если просто object юзать это тоже плохо?

ну тут экстешен, а если я не могу применить ее как экстешен

Это вопрос про интероп?

а если просто object юзать это тоже плохо?

их неудобно использовать из котлина + там появляется реальный объект

ну тут экстешен, а если я не могу применить ее как экстешен

Слушай, ну классы же ты как-то находишь. Чем функции отличаются в этом контексте?

Слушай, ну классы же ты как-то находишь. Чем функции отличаются в этом контексте?

ну в java я могу сделать так дернуть к примеру Utils. и посмотреть какие там методы есть

а так мне придется лезть внутрь

я возможно бред несу... я не силен в котлине

ну в java я могу сделать так дернуть к примеру Utils. и посмотреть какие там методы есть

double shift + имя файла

а так мне придется лезть внутрь

Я про сами классы. Откуда ты знаешь, где и какие классы есть? Вот оттуда же ты в котлине кроме классов найдёшь функции. Обычно это документация :)

тут все в 1 куче будет и концов не соберёшь

<spoiler>не надо валить в кучу</spoiler>

а так мне придется лезть внутрь

В крайнем случае чисто из IDE можно написать имя пакета и смотреть список функций там. Потом нормальный импорт посредством Alt+Enter сделать. Но мне ни разу пока не приходилось чёт так искать.

<spoiler>не надо валить в кучу</spoiler>

вооо а как это сделать красиво в котолине?

вооо а как это сделать красиво в котолине?

Дык пакеты же и файлы.

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

а если делать top-level будет каша всегда

и только лезть в сам класс и смотреть что там есть

а если просто object юзать это тоже плохо?

да ничего плохого, язык позволяет, значит можно. Просто top level и extensions это более идеоматично и стоит отдавать им предпочтения, но если хоется object declaration - то пожалуйста, никто не мешает.

и не дай бог нейминг похожий... то вообще жопа

а если делать top-level будет каша всегда

Ещё раз а) документация б) список функций в пакете в) действительно заглянуть в сорцы Ты попробуй сначала поработать, к примеру, со стандартной библиотекой, которая во многом так сделана, а потом критикуй :)

а если делать top-level будет каша всегда

зависит. Если utils связаны с конкретным классом - экстеншены ни чем не отличаются, и интелисенс получешь прямо на объекте.

да ничего плохого, язык позволяет, значит можно. Просто top level и extensions это более идеоматично и стоит отдавать им предпочтения, но если хоется object declaration - то пожалуйста, никто не мешает.

ну top level хорошо когда extensions функции? или не обязательно?

Ещё раз а) документация б) список функций в пакете в) действительно заглянуть в сорцы Ты попробуй сначала поработать, к примеру, со стандартной библиотекой, которая во многом так сделана, а потом критикуй :)

не не, я просто пытаюсь понять, возможно не правильно выражаюсь

не не, я просто пытаюсь понять, возможно не правильно выражаюсь

Для того, чтобы проникнуться, надо потыкать. На словах тебе этого никто не объяснит.

ну top level хорошо когда extensions функции? или не обязательно?

Extension methods на не топ-левеле лексически замкнуты (невидимы извне), так что - только топ левел

Для того, чтобы проникнуться, надо потыкать. На словах тебе этого никто не объяснит.

ок благодарю, буду изучать

Для того, чтобы проникнуться, надо потыкать. На словах тебе этого никто не объяснит.

самый дельный совет :)

@dmitry_konurov плюс смотри пояснение в одкументации https://kotlinlang.org/docs/reference/classes.html последний пункт "Companion objects"

@dmitry_konurov плюс смотри пояснение в одкументации https://kotlinlang.org/docs/reference/classes.html последний пункт "Companion objects"

спасибо