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

ServiceLoader

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

тогда получится Android ?

ServiceLoader

Service Locator т.е.)

Что в общем-то не DI

Service Locator т.е.)

и чем плох ServiceLocator в данном случае?

и чем плох ServiceLocator в данном случае?

Все тем же - ошибки на рантайме

Все тем же - ошибки на рантайме

какие еще ошибки?

А у нас же тръ фп, компайл там.

у тебя есть context и в нем есть все что может понадобится любому плагину, нет?

Все тем же - ошибки на рантайме

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

какие еще ошибки?

ну выше вы с Andrey объясняли самый широкий спектр ошибок к оторым приводит container di

Окей, а каков твой подход? Ведь ты же тоже предлагаешь ServiceLocator

просто формат немного другой, разве нет?

Я говорю что есть куча задач где не будет в вашем DI никакой compile-time safety. И как пример привожу вот эту задачу.

И вот тут spring намного лучше бы отработал

т.к. он проинициализировал зависимости не только у Plugin, но и у всех зависимостей Plugin внутренних.

Я говорю что есть куча задач где не будет в вашем DI никакой compile-time safety. И как пример привожу вот эту задачу.

«Если хоть где-то нет compile-time safety, давайте вообще выбросим его.»

«Если хоть где-то нет compile-time safety, давайте вообще выбросим его.»

У меня почти в кажом проекте рабочем есть такого рода задачи. Да весь bootique на этом построен)

Да, такой вот не очень хороший подход, но plugin может хотеть любую часть core

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

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

Конечно, можно сказать что плагину лезть в кор не нужно, и это идеальное решение проблемы)

У меня почти в кажом проекте рабочем есть такого рода задачи. Да весь bootique на этом построен)

Что это?

Конечно, можно сказать что плагину лезть в кор не нужно, и это идеальное решение проблемы)

Ну так и надо сказать. Иначе у вас связность по коду появится.

Конечно, можно сказать что плагину лезть в кор не нужно, и это идеальное решение проблемы)

А можно сделать сервисЛокатор явным и не закладываться на особенности реализации и не ломать совместимость.

Ну так и надо сказать. Иначе у вас связность по коду появится.

Только проблема в том что плагин может и в базу захотеть сходить, и черти что.

Я говорю что есть куча задач где не будет в вашем DI никакой compile-time safety. И как пример привожу вот эту задачу.

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

То есть разделение на core и plugin у вас не работает де факто. Фактически, у вас монолит.

передавать локатор и передавать граф - разные вещи

Только проблема в том что плагин может и в базу захотеть сходить, и черти что.

Зачем плагину самому ходить в базу? Он должен поход в базу делегировать core через предоставленное интерфейсом API

Только проблема в том что плагин может и в базу захотеть сходить, и черти что.

а смысл тогда иметь отдельный плагин?

а смысл тогда иметь отдельный плагин?

Вот и я не пойму, зачем в связанном по коду монолите что-то называть плагином. Оно от этого плагином не станет.

Зачем плагину самому ходить в базу? Он должен поход в базу делегировать core через предоставленное интерфейсом API

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

а смысл тогда иметь отдельный плагин?

В том что есть core, и каждый клиент может этот core расширять как ему хочется. Без перекомпиляции

В том что есть core, и каждый клиент может этот core расширять как ему хочется. Без перекомпиляции

...и без совместимости

что отвалится в следующей версии — никто не знает

...и без совместимости

Core очень стабилен просто, старое не выкидывается, а надолго деприкейтится. Опять же это аут оф скоуп

В том что есть core, и каждый клиент может этот core расширять как ему хочется. Без перекомпиляции

И без безопасности. Любой клиентский плагин может с чем угодно творить что угодно. Беспредел прям и анархия.

Core очень стабилен просто, старое не выкидывается, а надолго деприкейтится. Опять же это аут оф скоуп

вот пусть оно всё будет засунуто в локатор тогда

Core очень стабилен просто, старое не выкидывается, а надолго деприкейтится. Опять же это аут оф скоуп

ну значит у него есть какое-то стабильное апи для получения зависимостей

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

Я не пытаюсь уменьшить скоуп. Смысл в том, чтобы явно декларировать, на что плагин может рассчитывать. Это и есть интерфейс core

В общем резюмируя, вы предлагаете все что я нежно ручками в core main насоздавал, запихнуть в мапу, или в мапу обернутую в интерфейс и передать в метод Plugin.setContext(deps)?

В общем резюмируя, вы предлагаете все что я нежно ручками в core main насоздавал, запихнуть в мапу, или в мапу обернутую в интерфейс и передать в метод Plugin.setContext(deps)?

Ни в коем случае. В интерфейс или несколько, представители которых и будут переданы плагину. Инкаких мапов.

В общем резюмируя, вы предлагаете все что я нежно ручками в core main насоздавал, запихнуть в мапу, или в мапу обернутую в интерфейс и передать в метод Plugin.setContext(deps)?

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

почему контекст ассоциируется с мапой?

Ни в коем случае. В интерфейс или несколько, представители которых и будут переданы плагину. Инкаких мапов.

> или в мапу обернутую в интерфейс

В общем резюмируя, вы предлагаете все что я нежно ручками в core main насоздавал, запихнуть в мапу, или в мапу обернутую в интерфейс и передать в метод Plugin.setContext(deps)?

Не в мапу, а в объект, где у всего этого будут типы. И передавать в конструктор единственным параметром.

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

> или в мапу обернутую в интерфейс

почему контекст ассоциируется с мапой?

Потому что не все работали с андроидом ?

> или в мапу обернутую в интерфейс

Нет, не в мапу. Мапа сотрёт типизацию.

Ну условно. В такой жирный класс, в которым X полей просто для того чтобы использовать его дальше как service locator

> или в мапу обернутую в интерфейс

как хочешь, главное чтобы все втои зависимости лежали в ней еще в compile-time

Ну условно. В такой жирный класс, в которым X полей просто для того чтобы использовать его дальше как service locator

Что значит условно мап?

Map из Class<T> в T ?

Что значит условно мап?

В такой жирный класс, в которым X полей просто для того чтобы использовать его дальше как service locator

В такой жирный класс, в которым X полей просто для того чтобы использовать его дальше как service locator

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

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

Ну теоретически так конечно можно написать, только на практике получится ужасный шаблонный код

Ну теоретически так конечно можно написать, только на практике получится ужасный шаблонный код

Я так пробовал. Какой-то ужасной шаблоности не заметил. Вот мапа действительно ужасна, так как для неё вообще ничего не проверяется во время компиляции.

вопрос допустим у меня есть иммутабельные data классы, то бишь все данные в них описаны как val я загружаю их содержимое из json и предположим некоторые их этих классов имеют ссылки друг на друга, причем циклические например, объект A имеет ссылку на B, а тот обратно и получается что чтобы создать A, его надо проинициализировать ссылкой на B, который уже создан но чтобы создать B должен быть готов A вопрос: можно ли такое как-то загрузить и создать?

Всё это восходит к рназнице между бестиповым лямбда исчислением и типизированным. В бестиповом выражения короче, но гораздо меньше возможностей проверки их корректности. В типизированном надо, о боже, писать сигнатуры типов. Зато проверка корректности хороша. Передача мапы, как вы предлагаете, пример бестипового выражения. КМК это противоречит идеологии Kotlin, так как он позиционируется, как строго типизированный язык.

вопрос допустим у меня есть иммутабельные data классы, то бишь все данные в них описаны как val я загружаю их содержимое из json и предположим некоторые их этих классов имеют ссылки друг на друга, причем циклические например, объект A имеет ссылку на B, а тот обратно и получается что чтобы создать A, его надо проинициализировать ссылкой на B, который уже создан но чтобы создать B должен быть готов A вопрос: можно ли такое как-то загрузить и создать?

А как вы изначально такие объекты создавали для сериализации в JSON?

А как вы изначально такие объекты создавали для сериализации в JSON?

ну например, в текстовом редакторе или еще каком-то снаружи

ну например, в текстовом редакторе или еще каком-то снаружи

А как у вас в JSON ссылка на объект описана, так что она циклическая? Что-то не представлю. Можно пример JSON?

например, по имени файла файл a.json { "friend": "\b.json" } файл b.json { "friend": "\a.json" } когда десериализую, поля friend должны превратиться в прямые ссылки на соответствующие объекты

вопрос допустим у меня есть иммутабельные data классы, то бишь все данные в них описаны как val я загружаю их содержимое из json и предположим некоторые их этих классов имеют ссылки друг на друга, причем циклические например, объект A имеет ссылку на B, а тот обратно и получается что чтобы создать A, его надо проинициализировать ссылкой на B, который уже создан но чтобы создать B должен быть готов A вопрос: можно ли такое как-то загрузить и создать?

зачем вообще так делать

зачем вообще так делать

надо

например, по имени файла файл a.json { "friend": "\b.json" } файл b.json { "friend": "\a.json" } когда десериализую, поля friend должны превратиться в прямые ссылки на соответствующие объекты

Так десериализуй friend как String

может быть есть другой способ решить задачу? например, указывать id друга а не друга целиком

ERROR: S client not available

Так десериализуй friend как String

потом пользоваться неудобно, надо хранить какой-то глобальный map<String,Any>, протягивать везде на него ссылку, кастить эти Any к нужным типам

Так десериализуй friend как String

Ну просто потом этап резолва в удобные объекты этой вакханалии

например, по имени файла файл a.json { "friend": "\b.json" } файл b.json { "friend": "\a.json" } когда десериализую, поля friend должны превратиться в прямые ссылки на соответствующие объекты

С точки зрения неизменяемости, одна из ссылок на объект должна быть ленивой. С точки зрения хаков - неизменяемые поля можно менять рефлексией ??

а еще можно не пытаться натянуть сову на глобус

а еще можно не пытаться натянуть сову на глобус

Можно, но человек не признаётся, зачем ему такое.

а еще можно не пытаться натянуть сову на глобус

есть данные в json они могут ссылаться друг на друга их надо загрузить в объекты они read only, то есть хотелось бы запретить их менять после загрузки почему сову?

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

но со ссылками

а почему бы не заменить ссылки на id (ссылки)?

ты ведь в JSON не пытаешься данные запечь в обхекты?

есть данные в json они могут ссылаться друг на друга их надо загрузить в объекты они read only, то есть хотелось бы запретить их менять после загрузки почему сову?

interface Friend { val friend: Friend } class ActualFriend(override var friend: Friend) : Friend Может так? Все как в жизни - говорят что навсегда, а на деле меняются)

Как заставить с этим работать ObjectMapper - для меня вопрос. Все эти ссылки врядли будут легко решаться на его уровне.

а почему бы не заменить ссылки на id (ссылки)?

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

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

кажется, что ок решение иметь хранилище, которое может в Id -> Friend. Гораздо лучше, чем уже иметь все ссылающееся на всех

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

кажется, что ок решение иметь хранилище, которое может в Id -> Friend. Гораздо лучше, чем уже иметь все ссылающееся на всех

придется везде тянуть ссылку на это хранилище и еще кастить при резолве в нужный тип, потому что он не один например класс A ссылается на класс B, класс C на класс D и так далее

придется везде тянуть ссылку на это хранилище и еще кастить при резолве в нужный тип, потому что он не один например класс A ссылается на класс B, класс C на класс D и так далее

а так не надо будет кастить?

а так не надо будет кастить?

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

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

а как ты сделаешь поле с динамически изменяемым типом? или А всегда ссылается на B?

если так, то передай ему функцию Id -> B

а как ты сделаешь поле с динамически изменяемым типом? или А всегда ссылается на B?

A всегда ссылается на B

ну тогда той штуке, которая работает с А не нужно ничего кастить, она всегда будет пользоваться Id -> B

ну тогда той штуке, которая работает с А не нужно ничего кастить, она всегда будет пользоваться Id -> B

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

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

interface Friend { val friend: Friend } class ActualFriend(override var friend: Friend) : Friend Может так? Все как в жизни - говорят что навсегда, а на деле меняются)

идея хорошая, но страшная )

Ну хз, котлиновский List так по сути работает

ну в принципе да

Сверху API Immutable, внутри muttable

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

прошил ссылки, отдал интерфейс - у тебя все immutable для клиента

есть данные в json они могут ссылаться друг на друга их надо загрузить в объекты они read only, то есть хотелось бы запретить их менять после загрузки почему сову?

fun main(args: Array<String>) { var b: B? = null val bRef: () -> B = { b!! } val a = A(bRef) b = B(a) println(a.b) println(b.a) } class A(bRef: () -> B) { val b: B by lazy(bRef) } class B(val a: A)

Как-то так мы сову на глобус и натянем

прошил ссылки, отдал интерфейс - у тебя все immutable для клиента

да, наверное надо будет подумать в этом направлении