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

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

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

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

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

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

Мне кажется, очень многие штуки, существующие с Java 1.0, делались по-быстрому

Мне кажется, очень многие штуки, существующие с Java 1.0, делались по-быстрому

я про то что equeals с hashcode - если и добавили для удобства то добавили все же в рамках концепта

т.е. использования всех полей класса

да, но это негибко в реальной жизни

ломать такой концепт - хз хорошо ли

просто это совсем неок переопределить хешкод для класса чтоб он работал с одним полем из 10

нужен ли сам концепт? Может, можно отказаться от него?

если нужен особенный кейс, можно сделать отдельно

(так, пора выдать себе предупреждение за флуд)

нужен ли сам концепт? Может, можно отказаться от него?

от ооп вообще?

если нужен особенный кейс, можно сделать отдельно

например, чтобы коллекции принимали сравнивающий делегат, как это делают Tree*

от ооп вообще?

нет)

например, чтобы коллекции принимали сравнивающий делегат, как это делают Tree*

привет автогенераторы хешкодов везде

в общем флуд жестокий, имхо compareTo не такой коммон случай, и фактически не может быть применим ко всем объектам в отличии от equals

в общем флуд жестокий, имхо compareTo не такой коммон случай, и фактически не может быть применим ко всем объектам в отличии от equals

имеет ли смысл equals для Future, ThreadPoolExecutor, Comparator, android.app.Activity?

имеет ли смысл equals для Future, ThreadPoolExecutor, Comparator, android.app.Activity?

только по ссылке

То есть не имеет.

только по ссылке

Зачем это разрешать вообще?

То, что что-то можно сравнить каким-то образом, не значит, что это нужно делать.

Но тем не менее от там есть.

Тогда почему compare не должно быть?

Как это могло бы выглядеть?

Примерно так https://pastebin.com/JT3d5xFM Синтаксис пока только теоретический, тк KEEP еще в обсуждение

Тогда почему compare не должно быть?

Речь о несферическом котлине вне вакуума?

Да, этот вопрос родился из решения конкретной задачи.

Да, этот вопрос родился из решения конкретной задачи.

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

То есть он не смог уйти от сумрачного наследия джавы.

То есть он не смог уйти от сумрачного наследия джавы.

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

Зачем это разрешать вообще?

а как отличать эти объекты друг от дружки?

а как отличать эти объекты друг от дружки?

Зачем?

сравнивать ссылки в managed-языке — не кажется ли странным?

сравнивать ссылки в managed-языке — не кажется ли странным?

различать объекты в ооп языке - не кажется ли нормальным?

различать объекты в ооп языке - не кажется ли нормальным?

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

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

ну хз, может мне джавовское ооп мозги проело

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

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

Ну, вот в моих кейсах сравнение по умолчанию не нужно никогда )

Народ, как красиво запустить N паралельнных URL(…).readText() (видимо через deferred) а потом собрать коллекцию длин этих строк, подставляя вместо упавших закачек -1? (Подвох в том, как сделать это без try/catch)

Народ, как красиво запустить N паралельнных URL(…).readText() (видимо через deferred) а потом собрать коллекцию длин этих строк, подставляя вместо упавших закачек -1? (Подвох в том, как сделать это без try/catch)

Java?

В Java есть URL.readText и Defrred<T>? Конечно в Котлин. Хочу понять как идиоматично чейнить suspend функции. Пока придумал через такой экстеншен: suspend fun <T> Deferred<T>.awaitResult(): Result<out T, out Exception> = try { Ok(await()) } catch (e: Exception) { Error(e) }

Вообще хочется понять имеет ли смысл писать такие фукнции: suspend fun downloadBytes(url: String): Result<ByteArray, Errors> С одной стороны ошибки видны в типе-функции, но как и с использование в Java/Scala Option<T> вместо T? есть подвох (компилятор не помешает функции все равно сделать сайд-эффект)

ну вот мне кажется что большого смысла нет

бери CompletableFuture просто

кому нужно сможет сделать cf.await(), а ты будешь цепочки писать

Можно конечно сослаться, что я под отсталый android пишу, но суть то не в этом, а в том что бы “эффекты” явно выражать, что бы отличать pure код/от кода с сайд-эффектами. Или смириться с тем что все suspend функции могут быть с некотролиролируемыми эфектами (исключения).

ну cf/rx как раз же чтобы эффекты контролировать

и асинхронно писать

Я имел ввиду джава или андроид ?

Хотя там конечно тоже джава ?

Добрый день. Подскажите, пожалуйста, можно ли на Kotlin написать мобильное приложение, которое будет работать под android и ios?(Прим: Xamarin для .NET)

см kotlin/native

см kotlin/native

Спасибо

В Java есть URL.readText и Defrred<T>? Конечно в Котлин. Хочу понять как идиоматично чейнить suspend функции. Пока придумал через такой экстеншен: suspend fun <T> Deferred<T>.awaitResult(): Result<out T, out Exception> = try { Ok(await()) } catch (e: Exception) { Error(e) }

Идеоматично тут как раз тупо бросать исключение.

Другое дело что не сильно удобно использовать будет.

ну cf/rx как раз же чтобы эффекты контролировать

Не вижу как CF позволяет лучше контролировать эффект, да и код получается сложнее https://pastebin.com/ztV0pJmN А у suspend тут есть явные преимущества: - компилятор явно запрещает вызвать код “делающий эффекты” (suspend) из обычного кода (с CF тебе никто не мешает вызвать метод возвращающий CF и забыть повесить обработчик) - с RX/CF твой код перестает быть простым и становится “монадическим”, состоящим из map/flatMap - кучу операторов надо запоминать (в rx с этим вообще беда)

Привет всем) Есть здесь люди, которые работали с KotlinJs?

Можно конечно сослаться, что я под отсталый android пишу, но суть то не в этом, а в том что бы “эффекты” явно выражать, что бы отличать pure код/от кода с сайд-эффектами. Или смириться с тем что все suspend функции могут быть с некотролиролируемыми эфектами (исключения).

А скажу крамольную мысль. "Некотонролируемые" исключение это не эффекты и не нарушают purity функций. Не pure функции это те, которые мутирует или зависит от какого-то левого стейта. Выкинутое исключение это всего-лишь результат функции. Просто любой fun foo(): T в Котлине, если его представить в хаскеле, на самом деле имеет тип результата Either<Throwable,T>, а "императивное" тело функции просто неявно заворачивается в do нотацию соответствующей монады. Т.е. самому делать это не надо. Эта монада уже встроена в язык.

Увы, эта монада иногда выстреливает.

ERROR: S client not available

Привет всем) Есть здесь люди, которые работали с KotlinJs?

kotlinjs - нет, но scala.js - тема

kotlinjs - нет, но scala.js - тема

жаль(

да не, все круто же

Да причем тут это? Я вроде бы не спрашивал, что лучше)

да не, все круто же

мы тут о котлине всё-таки

Да причем тут это? Я вроде бы не спрашивал, что лучше)

так я и не сравниваю

Увы, эта монада иногда выстреливает.

Так уж эта монада устроена. Если ничего специально не предпринимать, то исключение по умолчанию прокидывается выше. Собственно в Хаскеле вот Either монада вот ровно так работает, как ведет себя Котлин

Так уж эта монада устроена. Если ничего специально не предпринимать, то исключение по умолчанию прокидывается выше. Собственно в Хаскеле вот Either монада вот ровно так работает, как ведет себя Котлин

неужели Хаскелл не заставит обработать ошибку?

А скажу крамольную мысль. "Некотонролируемые" исключение это не эффекты и не нарушают purity функций. Не pure функции это те, которые мутирует или зависит от какого-то левого стейта. Выкинутое исключение это всего-лишь результат функции. Просто любой fun foo(): T в Котлине, если его представить в хаскеле, на самом деле имеет тип результата Either<Throwable,T>, а "императивное" тело функции просто неявно заворачивается в do нотацию соответствующей монады. Т.е. самому делать это не надо. Эта монада уже встроена в язык.

И тут вспоминается java с checked exceptions. Котлин повернул не туда ??

Нет. Если функция возвращает Either<E,T> и написана через do нотацию по этой монаде, то первая ошибка станет left результатом выполнения.

Хаскель заставит объявить тип результата как Either (или выведет) это да. В Хаскеле можно объвить функцицию которая никогда не кидает исключение (результат просто T) это да. Но только к purity это не имеет никакого отношения. В хаскеле есть panic который нельзя ни поймать ни представить типом.

Так что всё это одна фигня. Просто в одних языках (haskell, swift) ошибки делятся на исключения и паники (первые преставлены в типе и их можно поймать, а вторые не представлены в типе и их нельзя поймать). А в Котлине другой подход. Все ислючения можно поймать, но они не представлены в типе так как могут лететь отовсюду (среднее между паниками и исключениями), но зато есть удобный и легкий механизм работы с nullable значениями для преставления в типе ошибок вида "я не смог найти эту штуку" (когда не нужны подробности кроме сообщения о индикации того, что операция не получилась)

Почему бы (если хочется омазаться фп) весь код не разделить на 2 части? = Suspend функции, в которых делать: = - асинхронные запросы (в виде обычного имеративного кода, без всяких thenApply/flatMap) - IO (логично что IO должно быть асинхронным что бы потоки не лочить) - кидать исключения и прочие эффекты = Остальной код на “чистых” функциях = Тут запретить юзать IO/throw Котлин как бы к этом и поддталкивает, тем что можно вызывать из suspend обычный код, но НЕ наоборот. P.S. понятно что это программирование “по конвенции” и работать не будет.

собственно для этого и нужны были эти монадки, что они могут выражать собой эффекты, в частности побочные эффекты (внешний мир) и такое мы можем представить в виде вполне себе немагического типа и недавать программисту других путей вызывать побочные эффекты (но на самом деле давать unsafe тк язык прагматичный и всё всё равно скатывается в конвенции, но уверенности на порядок больше)

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

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

Пример GO показывает, что для удобной и предсказуемой многопоточности лучше НЕ юзать исключения

В Java есть URL.readText и Defrred<T>? Конечно в Котлин. Хочу понять как идиоматично чейнить suspend функции. Пока придумал через такой экстеншен: suspend fun <T> Deferred<T>.awaitResult(): Result<out T, out Exception> = try { Ok(await()) } catch (e: Exception) { Error(e) }

принимая откуда то Result есть опасение что там ещё и эксепшен может вывалиться (например в будущем если код перепишут)

Пример GO показывает, что для удобной и предсказуемой многопоточности лучше НЕ юзать исключения

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

https://habrahabr.ru/company/JetBrains/blog/339400/

Быть может кто-нибудь всё таки знает. Как данные строки будут выглядеть в kotlinjs? const { Botact } = require('botact') const bot = new Botact({ confirmation: CONFIRMATION, token: TOKEN }) Буду крайне благодарен за помощь)

external fun require(module:String):dynamic val Botact = require("botact") val bot = Botact(mapOf("confirmation" to CONFIRMATION, "token" to TOKEN)) как-то так

ну это если интероп с жсом, в чистом котлинжс будет попроще все)

да в чистом тоже думаю да) Но в том-то и дело, что либа написана на js

Сейчас буду пробовать. Спасибо!

Пытаюсь сделать debounce по аналогии с rx, но что-то получается больно много кода, мб можно как-то иначе, покрасивее? https://gist.github.com/romansl/d871727a247a3ea2209bf74e5170c95e

И вопрос в догонку: почему-то когда я вызываю job.cancel(), то ожидающий завершения job.join() не бросает CancellationException(). Вопрос: почему?

В примере это строка 26, она никогда не вызывается.

А почему он его должен бросать?