А зачем фактура если есть flow?

future имел ввиду

И не знаю, а как применить await к flow?

Кстати кто-нибудь щупал Java 9 java.util.concurrent.Flow? Если что он есть в бекпорте https://github.com/streamsupport/streamsupport

я смотрел реализацию в reactor-е и то как в 5 спринге это дело прикрутили

А вот если у меня достаточно большой gradle проект на Котлине, то как скажется на времени сборки разбивание его на несколько модулей?

Смею предположить, так что будет незаметно

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

Но надо будет больше системных ресурсов

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

скорее всего

Короче it depends

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

Но проблемы пофиксят, а модульность останется ?

мне вот реально пофиг 2 или 6 секунд всё собирается

мне вот реально пофиг 2 или 6 секунд всё собирается

Холодный старт в 8 минут, проект полностью на Kotlin, стоит SSD, build.gradle настроен)

мне вот реально пофиг 2 или 6 секунд всё собирается

2 или 6 минут было бы не пофиг)

Холодный старт в 8 минут, проект полностью на Kotlin, стоит SSD, build.gradle настроен)

А кроме ссд, рам и цпу какой?

согласен. Но... 8 МИНУТ?

Mac mini средний)

Братишка, у меня огромный OSGI проект собирался за 2

а если с демоном градле так вообще бывло за 1.3

согласен. Но... 8 МИНУТ?

Да, именно так. У меня конечно 8 оперативы, но все же это долго

Братишка, у меня огромный OSGI проект собирался за 2

Мы говорим о холодном старте?

Да, именно так. У меня конечно 8 оперативы, но все же это долго

Маловато 8 )

Маловато 8 )

SSD всего в три раза медленнее оперативки)

Не ну депенденси не качались, и не проверялось наличие новых

а так, обычный старт, с clean

хотя с clean там вроде 4 минуты было

Не ну депенденси не качались, и не проверялось наличие новых

У меня так же не малый проект

но 8 минут это круто

хотя с clean там вроде 4 минуты было

Я об этом. Это и есть холодный старт

ну я так делал, пришёл на работу, запустил, пошёл сделал кофе, и дальше работаешь нормально))

ну я так делал, пришёл на работу, запустил, пошёл сделал кофе, и дальше работаешь нормально))

Или взял себе JRebel)

С ним то норм)

эм, ну нет

для osgi?

у меня и так это работало более менее

"из коробки"

Для меня. Но я говорю с опыта, как есть, ведь был вопрос про проект на Kotlin

ну наверное на Java он бы тоже столько собирался.

Какой то очень большой проект или он делает во время сборки ещё майнинг биткоинов?

ну наверное на Java он бы тоже столько собирался.

На 20% быстрее)

Плюс annotation processing играет роль, там поговаривают что kapt просаживает

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

:(

fun `?`(arg: String) {}

как-то так даже можно)

fun `?`(arg: String) {}

Это минимум 3 символа

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

есть кейс. хочу чтоб была такая конструкция var mLoginBtn: Button = R.id.login_btn

при этом после присвоения int

а слева даже близко не инт

реально на котлине что-то похожее замутить?

на экстеншн функции

а чем https://kotlinlang.org/docs/tutorials/android-plugin.html не устраивает?

а его не надо анбиндить?

а его не надо анбиндить?

Нет

делегат + экстеншен функция сделают своё дело

делегат + экстеншен функция сделают своё дело

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

походу ссылка выше лучший вариант

который пока нашел

https://youtu.be/GrzG5zoMREs?t=328

private val btn: Button by findViewById(R.id.btn)

и никакой магии

всё в итоге не наллабл, финально и вообще ещё и бибикает

private val btn: Button by findViewById(R.id.btn)

и то есть каждый раз при обращении у меня вьюшка будет искаться?

один раз при первом обращении

тогда же надо добавить by lazy

на видео постепенно и подробное объяснение есть

реализация уже lazy в себе содержит

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

понял

но вот проблема

у класса Delagates нету метода lazy

И не нужно. lazy это функция в пакете

нежданчик

И делегат сам внутри lazy реализует, findViewById ни во что больше оборачивать не надо

то есть?

мне именно важно чтоб каждый раз не вызывалась функция инициализации

Она и не будет

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

Она и не будет

а если я пишу своего делегата?

с getValue

Или взял себе JRebel)

Да! ?

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

В поле

И потом возвращать

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

"И делегат сам внутри lazy реализует" - эта строка просто смутила

ну да, в классе делегата lazy-поле

т.е. еще один делегат