т.е. я конечно выкрутился без наследования, но осадочек остался

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

Что значит «наследник для extension-функции» и причём тут SAM?

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

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

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

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

Стоит ли брать "kotlin в действии"?

Типо неизменяемый интерфейс/изменяемый класс? Если не сложно минимальный пример, мне кажется можеть быть интересная задача.

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

Потому что комплексный конфигуратор не может быть от конфигуратора унаследован

Так как конфигуратор это экстеншн функция

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

Мне, например, ничего не понятно. Я знаю три формы extension-функций: объект функционального типа с ресивером, top-level extension-функция и member extension-функция. typealias я могу себе представить только для функционального типа. Кто от кого не может быть унаследован?

Тип Project.()->Unit от него класс унаследован быть не может. Так мне компилятор сказал по крайней мере

Тип Project.()->Unit от него класс унаследован быть не может. Так мне компилятор сказал по крайней мере

Можно унаследовать от (Project) -> Unit, результат будет тот же.

Можно унаследовать от (Project) -> Unit, результат будет тот же.

технически ты абсолютно прав, проблема только в том, что я-то сделал тип typealias ProjectConfigurator = Project.()->Unit и теперь хочу, чтобы мой комплекс-конфигуратор тоже был проджект-конфигуратором, однако сделать так нельзя. Я конечно могу унаследовать его от функции и делать вид, что всё ок, но в строготипизированном смысле он конфигуратором не будет. Это наверное больше проблема тайпалиасов, конечно, но суть не меняется. Я бы был вполне доволен в этой ситуации, если бы мне просто дали возможность просто инстанцировать функциональные интерфейсы

технически ты абсолютно прав, проблема только в том, что я-то сделал тип typealias ProjectConfigurator = Project.()->Unit и теперь хочу, чтобы мой комплекс-конфигуратор тоже был проджект-конфигуратором, однако сделать так нельзя. Я конечно могу унаследовать его от функции и делать вид, что всё ок, но в строготипизированном смысле он конфигуратором не будет. Это наверное больше проблема тайпалиасов, конечно, но суть не меняется. Я бы был вполне доволен в этой ситуации, если бы мне просто дали возможность просто инстанцировать функциональные интерфейсы

Да, согласен. То же самое недавно было, когда я пытался заимплементить suspend () -> ....

а есть интеграция старого java.util.concurrent.Future с корутинами?

Если бы у меня был выбор, я бы его и не использовал ?

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

экстеншен потому что красивее

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

ну я так понимаю, у Future нет коллбека или чего-то такого, поэтому непонятно, когда пробуждать корутину

можно только сделать .get() и надеяться, что не заблокируешься или таймаут поставить

Это фак(т).

ну я так понимаю, у Future нет коллбека или чего-то такого, поэтому непонятно, когда пробуждать корутину

просто не саспендить?

так тогда весь поток заблокируется, и весь профит корутин уйдёт в никуда?

ну да

у тебя же блокирующее апи - получай удар по своему перфекционизму

лол)

нет, можно создать event loop, который будет тыкать палочкой в эти фьючи)

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

кстати как?)

Вроде в гуаве есть годные фьючеры

кстати как?)

tpe#submit, future#get

Если комплитабл нет возможности использовать

Вроде в гуаве есть годные фьючеры

ну и в корутина фьючи есть. просто задача не та

tpe#submit, future#get

ну я подумал что есть где-то функция чтобы джойнить фьючи

нет, можно создать event loop, который будет тыкать палочкой в эти фьючи)

Я вот тоже про ивентлуп подумал, даже будет работать, хоть и криво

https://github.com/Spikhalskiy/futurity

а есть интеграция старого java.util.concurrent.Future с корутинами?

Я правильно понял что у тебя есть CompletableFuture, но какой-то существующий API отдает тебе Future?

Я правильно понял что у тебя есть CompletableFuture, но какой-то существующий API отдает тебе Future?

Типа того, да

Ну тогда относительно неплохое решение - futurity

Гляну, спасибо

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

будет в 100 раз проще

или если тебе результат их интересует но не прям мнгновенно (например летенси в 10мс переживешь), то можно в обычный while(isDone) { delay(10) } внутри корутины завернуть проверку на готовность фьючи, а потом уже с чистой совестью делать get()

А правда что в андроиде нужно некоторый код запускать на UI потоке иначе он не выполнится(ну в смысле выполнится с исключением или выполнится не так как ожидалось)? Это сделано для того чтобы не нужно было синхронизировать состояние?

А правда что в андроиде нужно некоторый код запускать на UI потоке иначе он не выполнится(ну в смысле выполнится с исключением или выполнится не так как ожидалось)? Это сделано для того чтобы не нужно было синхронизировать состояние?

ios, android, js везде одинаково – есть глобальный цикл, в нём по очереди запускаются всякие колбеки, те изменяют вьюхи, потом по данным из вьюх рисуется фрейм. если изменяешь вьюхи не на ui потоке, то начинается недетерменнированный ад и постепенно сваливается эксепшен

точно не помню как это было

ну и на опенгл также делал с бесконечным циклом

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

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

Пример не с UI тредом но доступом из треда где объект создался есть в том же Realm https://realm.io/docs/java/latest/#threading

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

да

доставило проблем не мало в своё время

Вообще вроде практически все гуи фрейворки имеют UI поток.

Даже JavaFX

А вот Swing можно мутировать из нескольких потоков. Но никто не говорил, что это хорошо :)

Ну в свинге есть UI тред, и насколько помню всё перерисовку настойчиво рекомендуют делать на нём) Там invokeLater и тому подобное

Caused by: org.gradle.api.GradleException: Compilation error. See log for more details at org.jetbrains.kotlin.gradle.tasks.TasksUtilsKt.throwGradleExceptionIfError(tasksUtils.kt:8) - где найти этот лог?

Запустить gradle с --debug --stacktrace ?

Это и есть кусок стектрейса из гредла. Падает что-то в компиляторе котлина, и гредл не видит, что именно.

Это и есть кусок стектрейса из гредла. Падает что-то в компиляторе котлина, и гредл не видит, что именно.

Каков весь стектрейс?

Каков весь стектрейс?

https://pastebin.com/9cXKKFzX Проблема была в куче модулей и лишними compileOnly, возможно связано с флагами таргет апи 1.7, которые почему-то варнинги выдают (хотя стандартная либа для 1.7 своя есть). Если есть желание поковырять, могу дать доступ к проекту.

всем привет, потихоньку постигаю коаны, а не подскажете, как лечить No tests found for given includes: [test/i_introduction/_1_Java_To_Kotlin_Converter/N01JavaToKotlinConverterKtTest.kt]

в терминале выполняю кастомный тест ./gradlew test —tests test/i_introduction/_1_Java_To_Kotlin_Converter/N01JavaToKotlinConverterKtTest.kt

причем из гуи студии тест корректно проходит

Кстати, не было инфы, в kotlin-android-extensions не собираются сделать что-то вроде баттеркнайфовских onclick и пр?

Кстати, не было инфы, в kotlin-android-extensions не собираются сделать что-то вроде баттеркнайфовских onclick и пр?

Как в анко?

А вот это не знаю. Шо там в нем такое?

Сразу пишешь button.onClick {}

Кстати, не было инфы, в kotlin-android-extensions не собираются сделать что-то вроде баттеркнайфовских onclick и пр?

А смысла то нет

Будет даже хуже по читаемости

Будет даже хуже по читаемости

На вкус и цвет так то) Мне как в баттере сделано нравится, но тупо ради этого его тянуть нет желания, тем более, что все вьюшки есть через android-extensions

Ну вот, скорее всего вы просто привыкли к такому подходу. Чисто со стороны, написать метод отдельно под это имея ламбды и android-extentions в Kotlin, как-то не очень красиво.

Сахара не надо (с)

Сахара не надо (с)

А можно попросить три ложки?

А можно попросить три ложки?

Котлина мало? ?

Котлина мало? ?

А котлин лучше не мешать ?

Сразу пишешь button.onClick {}

onClick — это (довольно бесполезный) алиас для setOnClickListener. Не вижу смысла.

onClick — это (довольно бесполезный) алиас для setOnClickListener. Не вижу смысла.

А я не говорил что есть смысл...

Речь о не алиасах, а то чем-то вроде аннотаций в butterknife. Тобишь отдельный метод вешается сразу на вьюху. Это не идеально, но по мне красивше чем setOnClickListener

Речь о не алиасах, а то чем-то вроде аннотаций в butterknife. Тобишь отдельный метод вешается сразу на вьюху. Это не идеально, но по мне красивше чем setOnClickListener

Да, это классно. Это единственное, что мне нравится в маслоноже.

textView и progressBar по идее должны быть сверху и снизу центрального view, а это совсем не так

https://pastebin.com/8GQWBMbw

а, ну приведенный кусок кода — это содрежимое bottom sheet dialog

textView и progressBar по идее должны быть сверху и снизу центрального view, а это совсем не так

а по факту что? Можно скрин?

один момент

Могу файл с layout capture сбросить, скрин оттуда

а где текствьюшка?

Она вообще не видна, это тоже меня смущает. но, думаю, оно как-то связано

Кто нибудь пишет на котлин (JS)? Используете в продакшн?