EK
никогда не понимал смысл тэгов и наследований в контейнерах
Size: a a a
2020 May 03
V
добавил новый класс, потом надо не забыть его влепить в сервис провайдер
Тут ты прав, в ларке нет instanceof, но это уже проблемы ларки
EK
и какое это может иметь применение в здравом уме)
i
никогда не понимал смысл тэгов и наследований в контейнерах
Я тоже не понимал, пока не понадобилось
EK
а нафига?)
i
Тут ты прав, в ларке нет instanceof, но это уже проблемы ларки
ну вот я про то и говорю
V
никогда не понимал смысл тэгов и наследований в контейнерах
В тегах очень большой смысл. У тебя просто не было таких задач. К примеру, у тебя класс ждет набор классов, реализующих интерфейс. Будешь руками передавать каждый новый класс или запилишь тег, чтобы в класс передать
Command ...$commands?EK
В тегах очень большой смысл. У тебя просто не было таких задач. К примеру, у тебя класс ждет набор классов, реализующих интерфейс. Будешь руками передавать каждый новый класс или запилишь тег, чтобы в класс передать
Command ...$commands?какая разница что я буду проставлять тэги командам
EK
что просто просто проставлю массив комманд
V
ну вот я про то и говорю
Никогда не поздно написать свое расширение. Симфони же просто достает каждый класс и смотрит, есть ли конкретный интерфейс у
$reflection->getInterfaces(), и если да, ставит тегV
какая разница что я буду проставлять тэги командам
Потому что массив, а то вариадик
EK
ну вот у меня свой di
EK
и там вопрос решен очень просто
EK
если аргумент variadic то используется имя аргумента
EK
в данном случае commands
V
если аргумент variadic то используется имя аргумента
А если несколько интерфейсов?
EK
я просто в контейнер регаю зависимость commads в виде массива, которая содержит в себе объекты имплементищие Command
i
а нафига?)
Пример, нужно реализовать сидеры из ларки.
В симфони пишем:
Потом просто инжектим iterable $dataSeeders в команду
И не надо каждый отдельный сидер в конфиге описывать, все единообразно отработают
В симфони пишем:
_instanceof:
App\Service\Seeder\SeederInterface:
tags: ['app.data_seeders']
Потом просто инжектим iterable $dataSeeders в команду
run-seeds, к примеру. И там внутриpublic function make(iterable $dataSeeders)
{
foreach ($dataSeeders as $seeder) {
$this->runSeeder($seeder);
}
}
И не надо каждый отдельный сидер в конфиге описывать, все единообразно отработают
V
я просто в контейнер регаю зависимость commads в виде массива, которая содержит в себе объекты имплементищие Command
Не вижу преимуществ перед тегам ларки или instanceof симфони
EK
А если несколько интерфейсов?
commands => function (Container $container) {
return [
$container->get(A::class),
$container->get(B::class),
]
}
return [
$container->get(A::class),
$container->get(B::class),
]
}