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

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

зависимости со стейтом?

Если я не туплю, то это сработает только если мы сразу запускаем что-то из обсуждаемого объекта в том же обработчике. А если нам надо дальше в цепочке передать?

например, symfony normalizer интерфейс говно, потому что он подразумевает NormalizerAwareInterface с методром setNormalizer. вместо этого надо было сделать normalize($data, ..., NormalizerInterface): mixed

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

и никакой мутации сервиса через сеттер не надо

@openvz https://github.com/php-service-bus/demo/blob/v5.0/src/Customer/Registration/WhenRegisterCustomerValidationFailed.php#L24

Тогда не получиться передать дальше в цепочке. Или же нужно ещё в цепочке делать интерфейс для шаринга рандомных данных. В принципе, так было сделано в потоках (pthreads), когда они ещё не сдохли.

В принципе, вариант, да

ага, да, оно

это не в принципе вариант, а то, как это надо делать)

резюмируя, есть только два нормальных типа инъекций — "фиксированные" (грубо говоря контейнер-компайл-тайм) через конструктор и "нефиксированные" (передаваемые в рантайме) через параметр выполняемого метода. тогда все сервисы можно делать иммутабельными, а весь контекст (представленный мутабельным стейтом и/или иммутабельными сервисами, выбираемыми для конкретной ситуации) живёт только в переменной и передается только через параметры, потом по окончании всех действий автоматически утилизируется.

Тогда и в роадраннере запускать проект можно смело, и корутинами баловаться, не боясь, что, например, в рамках одного процесса сначала в пошеренном нормалайзере один сериалайзер в свойстве через setNormalizer задан, а потом вдруг другой (в случае, если на проекте несколько сериалайзеров сконфигурировано под разные задачи, но при этом они шерят одни и те же SerializerAware нормалайзеры).

Кажется, это офигенная тема для практического видео на PHP Point, записал себе. Потому что так на словах вряд ли тут кто-то понял что-то)

Я понял ) Выше об этои писал, но не так подробно

`
public function doSmth(int $id, ?LoggerInterface $logger = null)`

да, только в этом случае прокидывать nullable странно, иначе клиенту всегда придется проверять !== null или ??= new NullLogger. чтобы облегчить клиенту жизнь, лучше сделать строго LoggerInterface в параметре, а на обрабатывающей стороне, если нечего, прокинуть NullLogger

ну как бы, если инъекцию делает контейнер и только он, то в конечном счёте наплевать, как она туда пришла
конечно паблик поле можно переписать
но положа руку на сердце, переписать можно и приватное через рефлексию

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