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

Роман, где ты раньше был (6 лет назад ??), когда проектировали язык?

А где был я? Мне не нравится, что лямбда и fun имеют разный синтаксис :)

на самом деле, будет круто, если реализуют subject variable in when и паттерн-матчинг. Ифы будут просто не нужны

Вот внутри when это гут (и петтернматчиг по data классам как в Scala) ?

А где был я? Мне не нравится, что лямбда и fun имеют разный синтаксис :)

Что-то не понял, а как бы хотелось?

Что-то не понял, а как бы хотелось?

Чтобы все функции объявлялись одинаковым (консистентным) синтаксисом, например, val work = { material: Material, instruction: Instruction -> }

Роман, где ты раньше был (6 лет назад ??), когда проектировали язык?

я вообще тогда не занимался ни джавой ни андроидом, под оракл писал =)

я вообще тогда не занимался ни джавой ни андроидом, под оракл писал =)

во, а я на пхп говносайты делаль

хотя нет, сайты вроде нормальные получились, но пхп больше не хочется.)

на самом деле, будет круто, если реализуют subject variable in when и паттерн-матчинг. Ифы будут просто не нужны

почему будут ифы не нужны? а else как?

хотя нет, сайты вроде нормальные получились, но пхп больше не хочется.)

да, аналогично

почему будут ифы не нужны? а else как?

when (val x = x, val y = y) { (null, null) -> ... (null, _) -> println(x) }

Роман, где ты раньше был (6 лет назад ??), когда проектировали язык?

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

when (val x = x, val y = y) { (null, null) -> ... (null, _) -> println(x) }

вполне годно, кстати

when (val x = x, val y = y) { (null, null) -> ... (null, _) -> println(x) }

да, нормально, хоть и не привычно

но если такое сделать, то и в if логично тоже самое добавить

Чтобы все функции объявлялись одинаковым (консистентным) синтаксисом, например, val work = { material: Material, instruction: Instruction -> }

Подожди, это сейчас валидная лямбда, а ты хотел бы: class MyClass { val doWork = { material: String, instruction: Int -> "hello world" } } Тут doWork считался методом?

будет свобода выбора

кроме того, не всегда нужно все кейсы обрабатывать, а when предполагает к этому

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

Я не считаю, что они в вакууме. Они не хотят тащить в язык ВСЕГО И ПОБОЛЬШЕ, и я с ними в этом более-менее согласен. Для каждый фичи должны быть серьёзные причины.

но если такое сделать, то и в if логично тоже самое добавить

или задепрекейтить ?

Подожди, это сейчас валидная лямбда, а ты хотел бы: class MyClass { val doWork = { material: String, instruction: Int -> "hello world" } } Тут doWork считался методом?

А я хотел бы стереть разницу. Лямбда === функция. :)

в ифе-то зачем?

в ифе-то зачем?

чтобы втащить в локальную область видимости

или задепрекейтить ?

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

А я хотел бы стереть разницу. Лямбда === функция. :)

а сейчас разве есть разница? синтаксически немного есть для разных кейзов, да, вцелом-то?

А я хотел бы стереть разницу. Лямбда === функция. :)

Если по честноку, я пишу такой код в продакшене: class AnalyticsFunctions( val send: (GoogleEvent) -> Unit = ignore(), val sendGoogle: (String) -> Single<Unit> = ignore()) и поля юзаю как методы

а сейчас разве есть разница? синтаксически немного есть для разных кейзов, да, вцелом-то?

Есть конечно. fun === метод, лямбда === анонимный класс.

Я не считаю, что они в вакууме. Они не хотят тащить в язык ВСЕГО И ПОБОЛЬШЕ, и я с ними в этом более-менее согласен. Для каждый фичи должны быть серьёзные причины.

тут я тоже согласен. тащить все не нужно

Есть конечно. fun === метод, лямбда === анонимный класс.

ну как там это внутри сделано это второй вопрос, это и поменяться может

а концептуально-то?

ну как там это внутри сделано это второй вопрос, это и поменяться может

Не может, потому что бинарная совместимость.

а концептуально-то?

Неконсистентно.

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

Не может, потому что бинарная совместимость.

так совместимость это не значит, что не может меняться, это значит, что не может меняться несовместимо :-)

Я не считаю, что они в вакууме. Они не хотят тащить в язык ВСЕГО И ПОБОЛЬШЕ, и я с ними в этом более-менее согласен. Для каждый фичи должны быть серьёзные причины.

Вот тут, однозначно да. Я тут как-то бегал-кричал что в Kotlin нужны "алиасы на пакеты", но через пару месяцев (да посмотрев как на Scala) в итоге понял всю мудрость авторов языка ? и перешел на object - ведь у них есть куча плюсов, по сравнению с функциями на топ левеле.

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

Вот. Заменить if паттерн-матчингом. Для консистентности ?

Паттерн match нарушает DRY принцип. В языке где нет кортежей нет места паттерн-матчу, а кортежы в котлине были выпилены вполне сознательно: https://blog.jetbrains.com/kotlin/migrating-tuples/

Паттерн match нарушает DRY принцип. В языке где нет кортежей нет места паттерн-матчу, а кортежы в котлине были выпилены вполне сознательно: https://blog.jetbrains.com/kotlin/migrating-tuples/

Есть же data классы, они же как кейс классы в Scala по которым есть паттерн-матчинг

Я бы всё, где есть component*, рассматривал как кортеж, например.

Do not repeat yourself (DRY). Если у вас есть data сlass у которого уже поименованы правильно поля, то зачем вам снова повторять эти меня завязывая на новые переменные с такими же именами?

Можно и не повторять. when (Pair(1, 2)) { (1, _) -> ... (_, 34) -> ... (_, _) -> ... }

Паттерн матч есть в языках где нету flow-sensiive typing. Это всё от древности. Наследие каменного века.

Да desctructuring в Kotlin это скорее зло, когда используется не с классами типа Pair/Triple а с произвольными data классами (я бы лично запретил).

Паттерн матч есть в языках где нету flow-sensiive typing. Это всё от древности. Наследие каменного века.

что такое flow-sensitive typing?

Та кже известный в народе как smartcast

да, так понятнее =)

Да desctructuring в Kotlin это скорее зло, когда используется не с классами типа Pair/Triple а с произвольными data классами (я бы лично запретил).

++, очень легко отрефакторить класс и потерять порядок

Та кже известный в народе как smartcast

Ну не знаю, мне кажется паттерн-матчинг удобнее, вот пример https://pastebin.com/hCrcaDNh Плюс меньше неоднозначностей. Ну да ладно, посмотрим что будет в 1.2/2.0

Ну не знаю, мне кажется паттерн-матчинг удобнее, вот пример https://pastebin.com/hCrcaDNh Плюс меньше неоднозначностей. Ну да ладно, посмотрим что будет в 1.2/2.0

2.0 не планируется :)

2.0 не планируется :)

Вообще? А я рассчитывал хотя бы к 2022)

Ну не знаю, мне кажется паттерн-матчинг удобнее, вот пример https://pastebin.com/hCrcaDNh Плюс меньше неоднозначностей. Ну да ладно, посмотрим что будет в 1.2/2.0

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

Вообще? А я рассчитывал хотя бы к 2022)

Андрей Бреслав сказал, что ломать ничего не собираются =)

Весь этот pattern match выглядит абсолютно не maintenable. Добавил к User еще один атрибут и что всё переделывать? write-only код получается

Проект типа "Сделать и забыть" — пойдет. А Котлин все-таки изначально задумывался как язык чтобы проще было писать и поддерживать проекты » 1MLOC постепенно переводя их с Java на Kotlin

Раз уж говорим про LOC, любопытство взяло: сколько строк кода в IDEA CE? :)

Весь этот pattern match выглядит абсолютно не maintenable. Добавил к User еще один атрибут и что всё переделывать? write-only код получается

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

Раз уж говорим про LOC, любопытство взяло: сколько строк кода в IDEA CE? :)

https://github.com/JetBrains/intellij-community/

Ну можно option atribute добавить, это раз. Но проблема не в этом. Проблема в том, что при росте числа атрибутов pattern match перестает быть удобен синтаксически. Он хорошо только для игрушечных примеров. С развитием и ростом кода, все-равно придется от них отказаться

https://github.com/JetBrains/intellij-community/

200к комитов, 106 веток, 48к релизов, 2% кода на Котлине... я подслеповат?)

нет, тут гитхаб не врет

интереснее сколько в ultimate

ERROR: S client not available

ну и еще тут плагины не учитываются

Ну можно option atribute добавить, это раз. Но проблема не в этом. Проблема в том, что при росте числа атрибутов pattern match перестает быть удобен синтаксически. Он хорошо только для игрушечных примеров. С развитием и ростом кода, все-равно придется от них отказаться

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

например https://github.com/JetBrains/intellij-community/search?l=kotlin https://github.com/intellij-rust/intellij-rust/search?l=kotlin

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

дата классами их как раз делают, потому что они тогда алекватно могут equals :)

ммм. ну тогда лучше бы в котлине был бы deriving

Ну можно option atribute добавить, это раз. Но проблема не в этом. Проблема в том, что при росте числа атрибутов pattern match перестает быть удобен синтаксически. Он хорошо только для игрушечных примеров. С развитием и ростом кода, все-равно придется от них отказаться

С таким подходом понятно почему весь интерпрайз на Java

Ну интерпрайз ещё долго на Java будет. Котлин позиционирует себя как язык прагматичный, для масс. Поэтому всё идёт через призму удобства и понятности.

Поясните знающие) в jvm в рантайме существует информация о параметрах типа дженериков?

Поясните знающие) в jvm в рантайме существует информация о параметрах типа дженериков?

насколько мне известно происходит type erasure. Т.е. во время компиляции дженерики заменяются кастами

поэтому в рантайме нет информации о типе дженерика

Но есть метод в джаве который их возращает)

Как он работает тогда?

какой метод?

ParameterizedType type = (ParameterizedType) screen.getClass().getGenericSuperclass(); Class screenClass = (Class) type.getActualTypeArguments()[0]; String geneticName = screenClass.getName();

Рабочий код

и что он возвращает?

List<MyClass> вернет "MyClass" ?

geneticName ?

Ну именно этот код нет

Но да

ParameterizedType type = (ParameterizedType) screen.getClass().getGenericSuperclass(); Class screenClass = (Class) type.getActualTypeArguments()[0]; String geneticName = screenClass.getName();

больно что нет переносов строк)

Вернет с именем пакета

интересно, хмм?

ну да интересно, что везде говорят что в рантайме информация о дженериках теряется

Ну именно этот код нет

https://docs.oracle.com/javase/tutorial/java/generics/erasure.html

вот пишут что стирается тип

Я ток могу предположить что метод выводит как то тип

ну ок тут статейку нагуглил

https://docs.oracle.com/javase/7/docs/api/java/lang/reflect/ParameterizedType.html

https://habrahabr.ru/post/66593/