Вот оно что))

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

ну так очевидно, что для того, чтобы что-либо сделать, нужны нечистые функции :)

Ну вот и ладненько. Такое тут любят. Просто называть такое синглтонами не любят, ибо не феншуй ?

android.app.Application так же плох, только в андроиде от этого зна не уйти

А в спринге же тоже нечто похожее на андроидовский Application

А вот это уже интересно. Чем плох android.app.Application, если это единственный "настоящий" синглтон, что гарантируется рантаймом? И чем он хуже, положим, процедурного main()?

Мужики -> @kotlin_mobile

А в спринге же тоже нечто похожее на андроидовский Application

спринг — это рассадник антипаттернов

Блин куда не ткнись - все зло:D

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

А вот это уже интересно. Чем плох android.app.Application, если это единственный "настоящий" синглтон, что гарантируется рантаймом? И чем он хуже, положим, процедурного main()?

Он не гарантируется. Есть ситуации, когда система подменяет твой Application из манифеста на android.app.Application :trollface:

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

Application заставляет Activity лезть в него за зависимостями. Так ведут себя синглтоны.

Это наверное очень плохо, да

Это наверное очень плохо, да

Отвратительно, потому что когда нужно, чтобы одна активити могла вести себя разными способами, появляется customizable object.

Мужики -> @kotlin_mobile

Протестую, андроид только как пример платформы, наравне со спрингом :)

Как же так, если одна активити ведет себя разными способами не является ли это злым паттерном нарушающим принцип single resposibility??

Активити -- интерфейс общения с системой, там SRP не может быть, если система это не предусмотрела.

Как же так, если одна активити ведет себя разными способами не является ли это злым паттерном нарушающим принцип single resposibility??

Если бы она могла иметь зависимости и делегировать решения им — нет.

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

Вы уж определитесь где болит

Протестую, андроид только как пример платформы, наравне со спрингом :)

А со спрингом в @kotlin_jvm

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

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

Нет, не может иметь конструктор с аргументами == не может иметь нормальных зависимостей.

А со спрингом в @kotlin_jvm

Ключевое слово было "пример", в чате JVM тоже за оффтоп выгонят, ибо это вопрос архитектуры.

Вы уж определитесь где болит

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

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

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

И даггер популярен именно по этой причине.

Равно как и тыща MV* фреймворков, которые пытаются спрятать костыли за своими интерфейсами.

Всё, я прекращаю оффтопить.

Равно как и тыща MV* фреймворков, которые пытаются спрятать костыли за своими интерфейсами.

О, внезапный единомышленник ?

Равно как и тыща MV* фреймворков, которые пытаются спрятать костыли за своими интерфейсами.

Не надо MVU вмешивать сюда ?

Аргумент. Задевать адептов чистоты и функциональщины не планировалось, речь шла сугубо о ведре, MVU -- это другая опера ? MVP и прочее, собственно, тоже в более общем плане -- хорошо. Просто API, предоставляемое ведром -- зло. Хотя в ведре и единой точки входа в привычном понимании нет. Что накладывает свои ограничения. Впрочем ладно.

Аргумент. Задевать адептов чистоты и функциональщины не планировалось, речь шла сугубо о ведре, MVU -- это другая опера ? MVP и прочее, собственно, тоже в более общем плане -- хорошо. Просто API, предоставляемое ведром -- зло. Хотя в ведре и единой точки входа в привычном понимании нет. Что накладывает свои ограничения. Впрочем ладно.

> и единой точки входа в привычном понимании нет В этом и есть корень зла.

При учёте, что Application всё равно создаётся при старте Activity / Service, если его не было, зависимости таки можно было и не выворачивать. But oh well, сначала об этом никто не подумал, а потом уже было поздно.

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

Да ладно, даггер их тоже синглтонами называет. Я же в шутку это писал :)

Хм, а чем DI плох для создания сущностей с гарантией единственности на уровне App? Spring или Guice - не важно. Все лучше, что встроенные в Котлин синглтоны, хотя бы протестировать можно и подменить реализацию )

Да тут скорее на любителя и от религии зависит))

Дык хорош, о том и речь. Я просто не сразу понял, что имеет ввиду тщ Quarx :)

Хм, а чем DI плох для создания сущностей с гарантией единственности на уровне App? Spring или Guice - не важно. Все лучше, что встроенные в Котлин синглтоны, хотя бы протестировать можно и подменить реализацию )

Тем, что такую простую вещь, как создание объектов, прячет от нас за трёхэтажные аннотации.

Люди, которые не вникают, что за аннотациями стоит, и без них бы творили страшное, а для остальных DI container -- просто инструмент, которым можно пользоваться, можно нет. В этом контексте не вижу смысла спорить, хорош он или плох. Тот же Spring Boot кроме DI уйму другой, гораздо более "страшной" магии делает.

Ну, Boot меня до сих пор пугает )

А вот на простой DI на котлиновских делегатах я бы посмотрел )

Там даже аннотации не нужны )

Как раз для грейдловой сборки такую себе замутил

Не хочу писать велосипед )

А там ничего кроме штатных котлиновских средств

В паблике или для чего-то закрытого?

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

а какую роль в этом Gradle играет?

Приятно что сборка и инстанцирования в одном месте. На базе конфига

То есть сам граф описан в конфигах сборщика? Хм. Скрипт генерит код точки входа?

а какую роль в этом Gradle играет?

Это для сущностей сборки контекст. Сборка такая здоровая, что в контексте два десятка бинов

А, понял наконец. Занятно :)

Quantum, представляешь себе андроид-проект с пачкой build.gradle.kts, которые тянут в buildscript dependencies Dagger 2 и сами им пронизаны? ? Звучит как страшилка на ночь)

Quantum, представляешь себе андроид-проект с пачкой build.gradle.kts, которые тянут в buildscript dependencies Dagger 2 и сами им пронизаны? ? Звучит как страшилка на ночь)

Что же в этом плохого?

Но для андроида сложно себе представить сбоку которой самой нужен di

Человек DI контейнеры не любит, я и предлагаю ему пофантазировать ?

Человек DI контейнеры не любит, я и предлагаю ему пофантазировать ?

Я же ваше написал, что для di контейнер вообще не нужен

Хотя не буду скрывать, у меня была мысль на счёт даггера ?

Да, но я же конкретно о даггере написал.

Всем привет

ERROR: S client not available

У кого-нибудь есть книгы по Котлину?

Вы уже смотрели на оф доки?

))

:D

Не было же в 1.2 ни List, ни ArrayList. Только Vector, только хардкор

Не было же в 1.2 ни List, ни ArrayList. Только Vector, только хардкор

Сарказм?

https://medium.com/contentsquare-engineering-blog/make-or-break-with-gradle-dac2e858868d

Не было же в 1.2 ни List, ни ArrayList. Только Vector, только хардкор

https://docs.oracle.com/javase/8/docs/api/index.html?java/util/List.html https://docs.oracle.com/javase/8/docs/api/index.html?java/util/List.html Они в 1.2 и появились.

По части синглтонов в Application есть еще такая идейка: накидав N штук туда, мы получаем что-то вроде Service Locator-а, мы даже можем юзать его как типичный SL (если сделать правильный дизайн). Но тут уже намечается другой холиварчик: SL vs DI. Мой выбор пока в сторону DI, SL юзаю только в ограниченных ситуациях.

на маленьких проектах на object AppContext только и сижу

единственное что, в самом коде юзаю не AppContext.service, а использую как дефолт аргумент в конструкторах

чтобы легко тестать было

исключение только main()

https://docs.oracle.com/javase/8/docs/api/index.html?java/util/List.html https://docs.oracle.com/javase/8/docs/api/index.html?java/util/List.html Они в 1.2 и появились.

Действительно. На Java ME их нет, поэтому думал, что JCF только в 1.5 завезли

Действительно. На Java ME их нет, поэтому думал, что JCF только в 1.5 завезли

https://docs.oracle.com/javame/8.0/api/cldc/api/index.html Since: 1.2, CLDC1.8 Правильно понимаю, что только в Java ME 8 версии ArrayList появился?

https://docs.oracle.com/javame/8.0/api/cldc/api/index.html Since: 1.2, CLDC1.8 Правильно понимаю, что только в Java ME 8 версии ArrayList появился?

CLDC 1.8 - это совсем не то, что крутится на мобилках По крайней мере, когда эта платформа была популярна

CLDC 1.8 - это совсем не то, что крутится на мобилках По крайней мере, когда эта платформа была популярна

Лан, оффтоплю уже, это для pro.jvm.

парни опять вопрос смеси старого проекта на джаве и новых файлов на котлине

джавовский класс с методом на вход хотят requestEach(final String... permissions)

внутр икотлина меня соотвесвенно Array<String>

как можно красиво это сделать?

*permissions

о крутяк

а как называется этот оператор *?

чтоб почитать

доку читать перед тем как работать с котлин))

https://kotlinlang.org/docs/reference/functions.html#variable-number-of-arguments-varargs