Ваш звонок очень важен для нас... продолжайте писать )

ха-ха, да ☝️

сейчас куча звонков по работе, очень сложно сконцентрироваться

Вообще говоря, мне нравится идея, что можно написать

def initialize(foo:)
  @foo = foo
end

А нечто поймет меня и само подгрузит/инстанциирует нужный Foo. Т.е. в идеале я  не хочу никогда писать никаких container.resolve или import ....
Чтобы все было лаконично и "по-рубишному". Но это уже попахвает автолоадом и магией. Как такое дебажить? Как работать с кодом (перепрыгиывать в определение нужного Foo)? Как такое сделать для любого фреймворка?

При этом dry-auto_inject работает почти что так. Так что я не до конца понимаю, почему он тебе так не нравится.
Только вместо контроллера надо написать import

Для сравнения

class X
  include Import['foo']
end

class Y
  def initialize(foo:)
    @foo = foo
  end
end

На мой взгляд отличий нет. Надо явно указать правильное имя для разрешения зависимости. (И то и другое использует конструктор для передачи зависимости).

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

Но это все так далеко от "обычного" веб-приложения. Редко когда в своем коде нужна инверсия контроля.
Т.е. если она есть, то вроде бы и хорошо, и можно извлечь пользу. Но и так все хорошо работает )

Не хватает жизненных примеров, короче

def initialize(foo:)
  @foo = foo
end

class X
  include Import['foo']
end

class Y
  def initialize(foo:)
    @foo = foo
  end
end

1. dry-container “навязывает” своё присутствие в коде конструкцией “include Import['foo’]”. Канонического TDD не получится, придётся такщить контейер во все тесты или что-то мутить с заменой “Import”
2. конструкция типа include Import['foo’] явно не объявлет интерфейс конструктора объекта, хотя мы понимаем, что с точки зрения ООП “foo” должно бы передаваться именно через конструктор, как если бы никакого контейнера и не было.
3. ну и да, управление временем жизни компонентов. жить без этого конечно можно, но в некоторых случая действует реально круто.

Будет Tutorial на Dandy

За годы программирования мой язык оскуднел, одна статья занимает примерно месяц, поэтому не обещаю сделать это быстро.

Драй система так может

но первые 2 пункта остаются ж

1.  Контейнер тащить в тесты не надо - прекрасно работает Foo.new(bar: double). И есть вообще комбо - когда можно одну зависимость передать явно в конструктор, другую он возьмет из контейнера.
2. Да, согласен что непонятно. Особенно если несколько контейнеров(и такое бывает), но можно научится чить импорт, как парметры для конструктора. зато можно в консоли вызвать Foo.new и получить инстанс со всеми зависимостями без resolve.

Антон, сорян, не нашёл. где можно посмотреть как это делается?

Я познакомился с di еще работая на .net и все мне в подходе нравилось, кроме как простыни регистрации классов. А получение необходимых инстансов там разруливалось через интерфейсы. Но понятное дело в руби так не сделаешь. А первое зато наоборот легко решить - спасибо dry-system. Так что я считаю, что dry-container это отличный компромисс между каноничностью подхода и магией

фреймворк построенный на DI должен скрывать все эти простыни. Тестовый фреймворк Dandy, построенный на Hypo, не предполагает регистрацию компонентов руками. да, я тоже пришёл из .net в 2011, многие вещи заимствованы из Castle Windsor. как и сейчас в Ruby, тогда контейнеры не были мейнстримом, это был не “Microsoft way”. Сейчас всё поменялось, есть .NET Core, но там уже совсем другой ад.

так оно и скрывает же :)

дьявол в деталях

Если про сокрытии это к dry-container, то с помощью dry-system он скрывает это дело. А еще делает возможность загрузки on-demand

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