ресиверы в extension функциях - это не такая уж давно известная вещь.

в комбинации с синтаксисом из груви, который известен, но работал по-другому

а кто работал с вебсокетами ? я вот сначала взял ktor, не зашло, как-то неюзабельно потом перешел на spark, но там 2 строчки которые абстракцию создают с 3 классов в итоге выкинул spark и сервер на jetty теперь без абстракции в виде spark

ресиверы в extension функциях - это не такая уж давно известная вещь.

Ну вообще такой паттерн испокон веков был реализуем на JavaScript. Если я правильно понял что за ресивер

ресиверы в extension функциях - это не такая уж давно известная вещь.

Интересно, кто-нибудь юзает ext-лямбды, для чего-то кроме dsl?

В котлине есть объекты типа A.() -> Unit, которые используют первый аргумент как контекст исполнения. Это создает все мнообразие DSL-плюшек и многое другое. Я не знаю JS, но чего-то я там такого не помню

Интересно, кто-нибудь юзает ext-лямбды, для чего-то кроме dsl?

еще как

По крайней мере я использую в куче мест

По крайней мере я использую в куче мест

+

Я писал пост на форуме щас найду

Интересно, кто-нибудь юзает ext-лямбды, для чего-то кроме dsl?

run и apply же, ну

run и apply же, ну

Всегда считал их недо-dsl (по крайнемере, они как билдеры юзаются)

В котлине есть объекты типа A.() -> Unit, которые используют первый аргумент как контекст исполнения. Это создает все мнообразие DSL-плюшек и многое другое. Я не знаю JS, но чего-то я там такого не помню

возможно вы про bind, apply call в js bind`ом и apply точно можно подменить контекст

Э, это динамическое присабачивание методов, это совсем не то. Я про статическое разрешение

Э, это динамическое присабачивание методов, это совсем не то. Я про статическое разрешение

не совсем понял как это статическое присобачивание методов

ресиверы в extension функциях - это не такая уж давно известная вещь.

Ну первые иде внес шарп, а jb улучшило идею

Что я вам хочу сказать, дамы и господа. Kotlin-плагин IDEA версии 1.3.20-dev-75, org.jetbrains.kotlin.multiplatform версии 1.3.0-rc-6 — идея умеет по контрол-клику бегать в stdlib нейтива, показывая декомпилированное содержимое *.knm-файлов :)

Нашел: https://discuss.kotlinlang.org/t/spreadsheet-for-differences-between-let-with-run-apply-and-also/5029/12?u=darksnake

не совсем понял как это статическое присобачивание методов

https://kotlinlang.org/docs/reference/extensions.html

а вы про это именно как у kotlin реализации нету, но всякие обходные пути есть в виде const obj3 = Object.assign( obj1, obj2 ) или Object.assign(this, { x, y }); вот еще MyClass.prototype.foo = function (arg1, arg2) { ... };

что тут происходить ?

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

Вообще, на примере JS обсуждать хоть что-то статическое - это странно.

@HeapyHop у тебя есть какие-то лайфхаки как с junit бороться кроме как runBlocking в каждую функцию пихать?

@HeapyHop у тебя есть какие-то лайфхаки как с junit бороться кроме как runBlocking в каждую функцию пихать?

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

runBlocking(TestCoroutineContext) даже вот так

но хотелось бы что-то в духе @Test suspend fun `Wow my cool test`() {

runBlocking(TestCoroutineContext) даже вот так

ну это очевидно оборачивается в какую-нибудь coTest функцию

Теоретически для junit 5 написать экстеншен можно ?

Но в иде поддержка сломается

надеюсь с этим что-то придумают

https://junit.org/junit5/docs/current/api/org/junit/jupiter/api/extension/TestInstanceFactory.html

Ну визуально кажется можно прямо сейчас запилить такой экстеншен который будет резолвить suspend методы с аннотацией тест как тесты. Но опять же - нужен будет еще и плагин для idea чтобы ранать индивидуальные тесты из неё

надо в исходниках ktor поглядеть

а что там?

а вот смотрю, обычный runBlocking либо функция с ним

Хотя экстеншенами не обойтись, нужно делать TestEngine

fun <T> runBlockingTest(block: suspend CoroutineScope.() -> T) = runBlocking(TestCoroutineContext()) { block() Unit }

такую хрень запилил в общем

Ну да, это нормальный вариант

Там suspend main везут, кстати :)

где?

где?

https://github.com/JetBrains/kotlin/commit/c3f6ba3302332a2c2bea8dd5fcc521535c5730d8

круто, спасибо)

Вообще, на примере JS обсуждать хоть что-то статическое - это странно.

Кажется мы обсуждали фичу, а не то что тут ещё есть и статика. Понятно что в js никакой статике нет и в помине. А так что тут устанавливается this в скоупе функции, что в js

Там suspend main везут, кстати :)

А вот это прикольно, прямо как в хаскеле main args -> IO

@HeapyHop у тебя есть какие-то лайфхаки как с junit бороться кроме как runBlocking в каждую функцию пихать?

Блин, короче я закопался в написании своего TestEngine, пока все выглядит многообещающе.

Блин, короче я закопался в написании своего TestEngine, пока все выглядит многообещающе.

?

Кажется мы обсуждали фичу, а не то что тут ещё есть и статика. Понятно что в js никакой статике нет и в помине. А так что тут устанавливается this в скоупе функции, что в js

Вообщем в js статическое присобачивание чего либо это манки патчинг

Good morning everbody #question #creatingDirectories I created folders inside folder in ExternalStorage , All folders have been created well , but when I check folders for .isDirectory() , it returns true only for first parent folder (MyAppFolder) and when checking other any inner folders for .isDirectory() returns false , my code is : val fileDirectory = File(Environment.getExternalStorageDirectory().path + File.separator + "MyAppFolder" + File.separator + "InnerFolder") if (!fileDirectory.exists()) { fileDirectory.mkdirs() } var myDownloadedFile = File(fileDirectory, fileName) if (!myDownloadedFile.exists()) { myDownloadedFile.createNewFile(); } is this logic is true way for creating folder inside folder , any suggestions ? thanks beforehand P.S. answers can be in russian language , I understand russian a little

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

Всегда считал их недо-dsl (по крайнемере, они как билдеры юзаются)

Тогда можно и операции над коллекциями считать dsl

кто-то пытался использовать котлин-реакт? насколько это юзабельно?

Для нефронтендера юзабельно. И даже удобно. Но нету редакса - его нужно самому запилить и тесты не запускаются из идеи

Для нефронтендера юзабельно. И даже удобно. Но нету редакса - его нужно самому запилить и тесты не запускаются из идеи

А для чего? ?

Юзал для написания ui стримингового микросервиса - было норм

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

Будет круто продолжить обсуждение kotlin/js и redux в тематическом чате @kotlin_js

Ну и ещё на нем писал реактовский туториал с tictactoe когда изучал kotlin js reactor с минимаксом. Логика на Котлине js норм

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

А что вы принципиально нового хотите? Для нового нужна новая математика в качестве обоснования, а у нас пока только лямбда исчисление да теория категорий. Врядли где-то, кроме параллельного программирования, будут особо новые подходы предлагать.

Тогда можно и операции над коллекциями считать dsl

А там ext-лямбды юзаются?, хм не видел такого

ERROR: S client not available

А там ext-лямбды юзаются?, хм не видел такого

я не про ext, говорил, ну да ладно. MvRx считается? там много ext лямбд

А там ext-лямбды юзаются?, хм не видел такого

Имено ext. Лямд, то это dsl, иногда будешь передавать резивер

я не про ext, говорил, ну да ладно. MvRx считается? там много ext лямбд

Они там, как в anko юзаются для UI?

Они там, как в anko юзаются для UI?

неа, для того чтобы стейт было удобно копировать setState { copy(title = newtitle) }

неа, для того чтобы стейт было удобно копировать setState { copy(title = newtitle) }

А мне кажется или они реально по анаташками генерят DSL? https://github.com/airbnb/MvRx/blob/master/sample/src/main/java/com/airbnb/mvrx/sample/views/BasicRow.kt

Это Epoxy

в нем они генерят dsl для компонентов, да

Можно ли как-то запустить тесты для xtandalone common модуля или для этого обязательно делать платформный модуль? По логике последнее, но мало ли...

Запустить на чем? -)

Об этом и вопрос

Конечно же на сферической виртуальной машине в вакууме

Ну вообще можно же коммон код пускать на всех доступных платформах ?Поэтому если сейчас например у тебя есть js и jvm, то там и запускать. Почему бы и нет

Можно ли как-то запустить тесты для xtandalone common модуля или для этого обязательно делать платформный модуль? По логике последнее, но мало ли...

Второе, ну хотелось бы что бы сделали первое

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

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

Общий код должен исполняться одинаково на всех платформах, следовательно скомпилить комон под любую доступную платформу, это просто упростить, и тесты будут правильно лежать и не лублироватся

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

да, так оно и есть

Да это без проблем. Просто для этого надо делать отдельный платформный модуль. Но вообще это логично

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

это раз

два, а вдруг под какой то платформой будет фэйл? не исключено

Второе - это понятно. Первое - а хочется common библиотеку

в смысле?

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

нет смысла тестить common код без платформы

как минимум потому что есть expected, который в common никак не запустишь

Я имею в виду релизить коммон код без платформного ваасче

не, тут все просто и правильно, в коммон либе в качестве бинаря шарится IR код, который еще может и что то ожидать, проект (не платформенная либа) уже ждет артифакт в готовом для подключения формате, даже если это kotlin/jvm - компилятор не принимает на вход IR по умолчанию. можно конечно подключить multiplatform плагин конкретной платформы к проекту напрямую и сказать что он его имплементит... это же уже не либа, может взлетит, но скорее всего будет подглючивать. да и к тому же неправильно это

Я имею в виду релизить коммон код без платформного ваасче

Этого вроде тоже пока не завезли, если я правильно помню.