Явно лучше, чем неявно - спорно, а вот компайл тайм лучше, чем рантайн - это априори

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

Тест с dryRun

я с деревни, чё это?

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

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

я с деревни, чё это?

Это значит написать unit-test (или интегрейшен, если хочешь без моков), который вызовет dryRun() и проверит форсированно весь граф

собсно к "явное vs неявное" и "компайлтайм vs рантайм" добавлю ещё кое-что DI контейнер — это обычно ещё и, как правильно Егор пишет, глобальное мутабельное состояние что тоже "не очень" мягко говоря

Это значит написать unit-test (или интегрейшен, если хочешь без моков), который вызовет dryRun() и проверит форсированно весь граф

это фича какого-то конкретного DI-контейнера?

это фича какого-то конкретного DI-контейнера?

Как я понимаю предполагается просто старт приложения сделать

Это Koin, вангую что в кодеине так же можно сделать

ммм вангую что в кодеине такое невозможно

там нет графа как такового, это вообще сложно на самом деле DI контейнером назвать

он ничего не знает о зависимостях классов

по сути это просто такой словарь KClass -> инстанс/провайдер/фактори/что-то там ещё

Хм, koin вроде тоже самое

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

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

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

а теперь представь, что тебе надо поменять инстанс какого-нибудь провайдера на другой в 10+ мест в приложении

а теперь представь, что тебе надо поменять инстанс какого-нибудь провайдера на другой в 10+ мест в приложении

Для этого короче придумали val

а теперь представь, что тебе надо поменять инстанс какого-нибудь провайдера на другой в 10+ мест в приложении

зафигачил бы фабрику и создавал бы инстансы через неё нужно что-то изменить — в одном месте меняешь фабрику в двух словах как-то так

зафигачил бы фабрику и создавал бы инстансы через неё нужно что-то изменить — в одном месте меняешь фабрику в двух словах как-то так

ну, т.е. замутил бы свой DI фреймворк?

ну, т.е. замутил бы свой DI фреймворк?

да

ну, т.е. замутил бы свой DI фреймворк?

азазаза

Фремйворк из одного фабричного метода

да

только без кодогенерации и NPE

Фремйворк из одного фабричного метода

ну не одного а в худшем случае по фабрике на каждую сущность которую я хочу инжектить

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

да ясно что это не будет DI-фреймворком)

даже близко

а потом ты бы сделал фабрику фабрик

В java мире вообще всё любят обзывать фреймворками

Фреймворк для сдвига строчки вправа

и получился бы...

и получился бы...

получился бы не DI-фреймворк

а потом ты бы сделал фабрику фабрик

@Harmonizr ну ты смотри “фабричный метод, фабричная фабрика - так и хочется леща дать” ?

@Harmonizr ну ты смотри “фабричный метод, фабричная фабрика - так и хочется леща дать” ?

?

а потом ты бы сделал фабрику фабрик

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

?

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

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

нет, они довольно большие, текст теряется

нет, они довольно большие, текст теряется

Вот мы чо то у себя в чатике не теряем текст

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

(x) => (y) => f(x,y)

(x) => (y) => f(x,y)

а, ну да ок, будут фабрики фабрик

как будто что-то плохое

(x) => (y) => f(x,y)

фу, типичный код на реакте)

Щас бы функции высшего порядка обзывать фабриками фабрик ?

Щас бы функции высшего порядка обзывать фабриками фабрик ?

ну собсна они изоморфны

Щас бы функции высшего порядка обзывать фабриками фабрик ?

не ну разве они не изоморфны друг другу?

надо короче просто на хаскеле писать, тогда не будет никаких "фабрик фабрик", "фабрик 5 порядка", будут просто каррированные функции :3

надо короче просто на хаскеле писать, тогда не будет никаких "фабрик фабрик", "фабрик 5 порядка", будут просто каррированные функции :3

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

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

но мы не ищем простых путей

Эт какие такие? F#?

??

F# мне не зашёл

всё из-за [file] order matters

Тут я точно спорить не буду, го в оффтоп-чат (хотя мы это уже обсуждали)

Тут я точно спорить не буду, го в оффтоп-чат (хотя мы это уже обсуждали)

мне щас лень, ну кинь ссылку на офтоп чят, я может попозже наброшу)

всё из-за [file] order matters

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

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

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

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

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

Как будто ты не делаешь манифест при сборке fatjar

Вернусь к вопросу про SAM в котлине

ERROR: S client not available

Оказывается он есть =O

для Java-интерфейсов

Ога, мне как раз для них надо было

Не понятно вот это: Also note that this feature works only for Java interop; since Kotlin has proper function types, automatic conversion of functions into implementations of Kotlin interfaces is unnecessary and therefore unsupported. Почему нет необходимости для котлин интерфейсов и что взамен?

лямбда

typealias... наконец до меня дошло

Не понятно вот это: Also note that this feature works only for Java interop; since Kotlin has proper function types, automatic conversion of functions into implementations of Kotlin interfaces is unnecessary and therefore unsupported. Почему нет необходимости для котлин интерфейсов и что взамен?

Взамен — функциональный тип.

Фабрики нужны, когда они нужны, и не нужны, когда не нужны, давайте не переусложнять.

Писать нормально и будет нормально! Согласен 100%

In pure Kotlin projects, the recommended directory structure is to follow the package structure with the common root package omitted (e.g. if all the code in the project is in the "org.example.kotlin" package and its subpackages, files with the "org.example.kotlin" package should be placed directly under the source root, and files in "org.example.kotlin.foo.bar" should be in the "foo/bar" subdirectory of the source root). я так понимаю до сих пор нельзя так делать, чтобы идея такое поддерживала?

In pure Kotlin projects, the recommended directory structure is to follow the package structure with the common root package omitted (e.g. if all the code in the project is in the "org.example.kotlin" package and its subpackages, files with the "org.example.kotlin" package should be placed directly under the source root, and files in "org.example.kotlin.foo.bar" should be in the "foo/bar" subdirectory of the source root). я так понимаю до сих пор нельзя так делать, чтобы идея такое поддерживала?

https://youtrack.jetbrains.com/issue/KT-23116 похоже на то

печально

Я так и не особо понял, чем здесь bg так уж отличается от async?

тем что контекст сразу задан

вдруг ты что-то блокирующее там пустишь

inline fun <T> bg(crossinline block: () -> T): Deferred<T> = async(POOL) { block() }

internal var POOL = newFixedThreadPoolContext(2 * Runtime.getRuntime().availableProcessors(), "bg")

internal var POOL = newFixedThreadPoolContext(2 * Runtime.getRuntime().availableProcessors(), "bg")

Спасибо. :)

вдруг ты что-то блокирующее там пустишь

Так, думал, что разобрался, но щас понял что не до конца. В чём будет принципиальная разница если мы запустим async вместо bg?

Он ведь так же проработает и дождется, нет?

у async дефолтный контекст будет DefaultDispatcher

Да

но я не знаю какой DefaultDispatcher на андроиде

на jvm возьмет ForkJoinPool

а у котлин-комьюнити есть свой модный json-парсер?

jackson, gson :)

https://github.com/Kotlin/kotlinx.serialization но модный вот

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

https://github.com/wizzardo/json-benchmarks

о, тогда будем рады бенчмарку kotlinx.serialization :)

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

Без кодогенерации, сериализация - тлен