Сообщение об ошибке бы.

возвращаемся на жаву, там как раз надо везде типы указывать, ясно и однозначно

не вижу в этом проблемы

ext.kotlin_version = '1.3.0-rc-116'

ext.kotlin_version = '1.3.0-rc-116'

Странно... Вроде прописал maven { url 'https://dl.bintray.com/kotlin/kotlin-eap' } Может, что-то другое надо?

не вижу в этом проблемы

Я вижу большую проблему в обратном. Котлин не обязывает указывать типы там, где это "очевидно"

не вижу в этом проблемы

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

Я вижу большую проблему в обратном. Котлин не обязывает указывать типы там, где это "очевидно"

я даже себе инспекцию включил чтобы орало на публичные объявления без типа

Да не правда это. Не за краткость, а за лаконичность.

Странно... Вроде прописал maven { url 'https://dl.bintray.com/kotlin/kotlin-eap' } Может, что-то другое надо?

Как Gradle-лагин подтягивается? apply plugin или plugins { ... }?

Да не правда это. Не за краткость, а за лаконичность.

ну ок, а разница в чем? я думал это одно и то же

pluginManagement { repositories { maven { url = 'http://dl.bintray.com/kotlin/kotlin-eap' } mavenCentral() maven { url = 'https://plugins.gradle.org/m2/' } } } buildscript { ext.kotlin_version = '1.3.0-rc-116' repositories { jcenter() maven { url = "http://dl.bintray.com/kotlin/kotlin-eap" } } dependencies { classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version" classpath "org.jfrog.buildinfo:build-info-extractor-gradle:4+" } }

Ну, в котлине вообще говоря сейчас идеальный вывод типов

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

Я не буду вступать в полемику о том, нужно ли указывать типы или выводить.

plugins { id 'org.jetbrains.kotlin.jvm'// version '1.3.0-rc-116' }

Я не буду вступать в полемику о том, нужно ли указывать типы или выводить.

а надо!

ну ок, а разница в чем? я думал это одно и то же

Разница в том, что надо не писать код там, где он очевиден, но не экономить там, где есть возможность разной трактовки

Ну и в корневом build.gradle plugins { id 'org.jetbrains.kotlin.jvm' version '1.3.0-rc-116' apply false }

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

Там есть путанница в том, где версия определяется, в сеттингах, в корневом модуле или в дочерних модулях. Я когда собирал методом перебора нашел работающий вариант

а не всё ок, у него всё покраснело ??

pluginManagement { repositories { maven { url = 'http://dl.bintray.com/kotlin/kotlin-eap' } mavenCentral() maven { url = 'https://plugins.gradle.org/m2/' } } } buildscript { ext.kotlin_version = '1.3.0-rc-116' repositories { jcenter() maven { url = "http://dl.bintray.com/kotlin/kotlin-eap" } } dependencies { classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version" classpath "org.jfrog.buildinfo:build-info-extractor-gradle:4+" } }

Странно, всё равно пишет Could not find org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.0-rc-116. Searched in the following locations: - https://dl.google.com/dl/android/maven2/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.pom - https://dl.google.com/dl/android/maven2/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.jar - https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.pom - https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.jar - https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.pom - https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.jar Required by: project :

а не всё ок, у него всё покраснело ??

Дык у него всё время краснеет и чинится, всё норм)

Так надо в билдскрипте репозиторий прописать. Иначе плагин не находит

Странно, всё равно пишет Could not find org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.0-rc-116. Searched in the following locations: - https://dl.google.com/dl/android/maven2/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.pom - https://dl.google.com/dl/android/maven2/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.jar - https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.pom - https://jcenter.bintray.com/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.jar - https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.pom - https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-gradle-plugin/1.3.0-rc-116/kotlin-gradle-plugin-1.3.0-rc-116.jar Required by: project :

подключил EAP-репу?

подключил EAP-репу?

maven { url 'https://dl.bintray.com/kotlin/kotlin-eap' } Да

Разница в том, что надо не писать код там, где он очевиден, но не экономить там, где есть возможность разной трактовки

если ты конкретно о моем вопросе, то я не настаиваю на форме ::toString для ссылки на метод инстанса элемерта списка.

maven { url 'https://dl.bintray.com/kotlin/kotlin-eap' } Да

в обоих местах?

maven { url 'https://dl.bintray.com/kotlin/kotlin-eap' } Да

В pluginManagement? Я не вижу, чтобы гредл искал плагин в kotlin-eap

в обоих местах?

А, лол, надо было в обоих. .—-. Спасибо, вопрос снят.)

А, лол, надо было в обоих. .—-. Спасибо, вопрос снят.)

Тоже от этого страдаю иногда.

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

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

кстати насчет Multiple Dispatch - кто-нибудь поминал, нет, в Котлин завезут? Или не нужен?

А он как бы уже есть

буквально вчера думал о том, что можно сделать await и обязать писать его

Глобавльные функции - это и есть multiple dispatch

но я еще не понел (может потом пойму) почему саспенд метод не возвращает просто какой-нибудь тип, значение которого можно сохранить, а можно на него сделатб await и ждать.

но я еще не понел (может потом пойму) почему саспенд метод не возвращает просто какой-нибудь тип, значение которого можно сохранить, а можно на него сделатб await и ждать.

Он так и делает

буквально вчера думал о том, что можно сделать await и обязать писать его

зачем обязать. обязать если хочешь заснуть тут. а если хочешь поспать потом или вообще в другой корутине.

Он так и делает

хм, а как тогда заснуть опциально? если нет эвэйта?

зачем обязать. обязать если хочешь заснуть тут. а если хочешь поспать потом или вообще в другой корутине.

собственно, разработчики корутин рассказали, почему sequential by default, а parallel только если нужно

Мне прям нравится подход чувака, докладывающегося про Gradle — он подправил build.gradle, потом он его переименовал в .kts, а дальше он пытается собрать из терминала и общеизвестные ошибки объясняет и исправляет. Как это делать новичкам — фиг знает.

Все асинхронные функции возвращают Deferred. Можно его как есть брать, можно await-нуть

Все асинхронные функции возвращают Deferred. Можно его как есть брать, можно await-нуть

false

Ну хорошо, не все.

они не асинхронные, если они возвращают deferred

оке почитаю дальше, а то я тока понаслышке тока слышал.

Все асинхронные функции возвращают Deferred. Можно его как есть брать, можно await-нуть

Большинство асинхнных функции так или иначе ожидают колбек

Кроме тех что fire and forget

они не асинхронные, если они возвращают deferred

А это что https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.experimental/async.html?

А это что https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.experimental/async.html?

собственно, она не suspend

Под капотом да. Но идейно, это же просто добавление существующему классу поведений, которые делают его квази-наследником интерфейса

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

Хорошо, понял, немного про разные вещи говорим. Но на суспенд функцию саму по себе await-то никто не навешивает

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

Я в принципе согласен, и в котлине это даже частично используется (в итераторах). Более того, мне идея тайп-классов самих по себе скорее нравится, чем нет. Проблема в том, что за ними тащут имплиситы, а вот это уже зло.

Я в принципе согласен, и в котлине это даже частично используется (в итераторах). Более того, мне идея тайп-классов самих по себе скорее нравится, чем нет. Проблема в том, что за ними тащут имплиситы, а вот это уже зло.

имплиситы такое же зло, как вывод типов

Хорошо, пока не не слишком много

Хорошо, пока не не слишком много

хорошо, пока <= 0

Я в принципе согласен, и в котлине это даже частично используется (в итераторах). Более того, мне идея тайп-классов самих по себе скорее нравится, чем нет. Проблема в том, что за ними тащут имплиситы, а вот это уже зло.

Если посмотреть на первоисточники тайп классов (вроде как Haskell, но ножет и ML), то там тайп классы и иммплиситы - совершенно разные фичи языка. При это имплиситы включаются только как расширения языка, так как они делают систему типов не разрешимой в общем случае.

хорошо, пока <= 0

Даже в джаву пихают var, потому что постоянно все явно писать невозможно. Чем плохи 2, 3 имплисита на класс, которые позволят уменьшить количество кода?

Даже в джаву пихают var, потому что постоянно все явно писать невозможно. Чем плохи 2, 3 имплисита на класс, которые позволят уменьшить количество кода?

тем что ревьювить сложнее? =)

Даже в джаву пихают var, потому что постоянно все явно писать невозможно. Чем плохи 2, 3 имплисита на класс, которые позволят уменьшить количество кода?

Не так уж и нужен этот var. Плохи они тем, что уменьшают качество. Я вот смотрел на Frege вчера и пытался понять, как оно работает. Ужас.

Мы уже минут 15 обсуждаем

Уже увидел

тем что ревьювить сложнее? =)

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

Не так уж и нужен этот var. Плохи они тем, что уменьшают качество. Я вот смотрел на Frege вчера и пытался понять, как оно работает. Ужас.

Нуу, фулл-ФП вообще штука сложная, поэтому Котлин так хорош, что в нем есть и элементы привычных парадигм, и хардовой функциональщины

Не так уж и нужен этот var. Плохи они тем, что уменьшают качество. Я вот смотрел на Frege вчера и пытался понять, как оно работает. Ужас.

> Frege Ты про внунтренние устройство компилятора или прикладной код?

> Frege Ты про внунтренние устройство компилятора или прикладной код?

both

ERROR: S client not available

Ну hello-word там не сложнее котлина ?

Даже в джаву пихают var, потому что постоянно все явно писать невозможно. Чем плохи 2, 3 имплисита на класс, которые позволят уменьшить количество кода?

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

Ну hello-word там не сложнее котлина ?

речь скорее идет про какие-то существующие проекты. Я как-то раз чекнул опенсорсный HTTP-сервер на Хаскеле и в ужасе закрыл

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

+

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

Это чой то? Где там динамика? Всё статически известно

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

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

А как имлиситы вообще связаны с груви?

А как имлиситы вообще связаны с груви?

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

Груви- это на самом деле очень хороший пример. Там наступили на насколько граблей, на которые второй раз наступать не надо.

В то числе трейты

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

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

Типы всё еще можно проверять на этапе компиляции

Скала разве так не делает? Я просто со Скалой мало знаком

Люди, которые знакомы с имплиситами в скале часто плюются на них со страшной силой.

Скала разве так не делает? Я просто со Скалой мало знаком

делает, но без IDE ты не разберешься с этим

ну либо без бутылки

а, ну без IDE я вообще не знаю, как люди на джаве/котле пишут Как минимум, из-за импортов

Ну так и на питоне без импортов никуда, и как-то пишут

Зависит от того, что писать

делает, но без IDE ты не разберешься с этим

С опытом приходит всё

Вобщем то в любом более менее большом проекте без ide не разберёшься

речь скорее идет про какие-то существующие проекты. Я как-то раз чекнул опенсорсный HTTP-сервер на Хаскеле и в ужасе закрыл

Но использовать его ты же можешь? Фреймворки обычно используют язык по максимуму, что пользователям как раз было легче.

Но использовать его ты же можешь? Фреймворки обычно используют язык по максимуму, что пользователям как раз было легче.

Да нет, я про код, который @Harmonizr вероятно увидел на Фреге

Я когда смотрю его код в reactive-property, тоже не комфортно себя чувствую ?

Корутины умеют в реактивные источники данных? То есть есть реактивный драйвер монги или webfluxовый webClient. Можно событие из реактивной пайпы получить корутиной? Только без блокирующего вызова .block() в suspend функции

https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/channels.md

ответ каналы видимо

да

Спасибо

Корутины умеют в реактивные источники данных? То есть есть реактивный драйвер монги или webfluxовый webClient. Можно событие из реактивной пайпы получить корутиной? Только без блокирующего вызова .block() в suspend функции

У kotlinx.coroutines есть пачка либ-байндингов к сторонним асинхронным и реактивным фреймворкам, но в случае с webflux webClient придётся по аналогии свой писать.

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