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

Мне ок.

Ну тогда я на второй способ бросаю иксепшин с not allowed in the event configurator

Хорошо.

Только не такой текст.

Пиши лучше, как нужно.

напиши

Incorrect event configuration. bla-bla-bla format should be used.

ок

А ивент сабскрайберс нам не нужны? Это в основном для кейсов с ручной отложенной сборкой листенеров, хз нужно оно или нет.

Это по аналогии с DeferredServiceProvider

Чтобы не дергать контейнер, пока событие не наступило

В этом случае даже кложи создаваться не будут до запроса листенера у провайдера.

Не понял.

Есть класс с интерфейсом EventSubscriberInterface, в нем методы getEventNames() и register(Provider $provider, ContainerInterface $container), в провайдере метод registerSubscriber() (или в кострукторе массив с сабскрайберами), котрый в массив с листенерами записывает сабскрайберы вместо листенеров, если вызван метод getListenersFor() проверяется перед отдачей листенера есть ли он объект с интерфейсом EventSubscriberInterface, если да, то регаем листенеры методом register и отдаем. Сами листенеры создаются в методе register, там же и дергается все из контейнера и инжектится. Как-то так. В итоге у нас листенеры создаются непосредственно при вызове событие, до этого регаются только сабскрайберы.

Особо не вижу профита.

Хотя, вместо register, лучше getListener($eventName, Provider $provider, ContainerInterface $container), чтобы только на конткретное событие регать

Ну такое, можно и позже сделать, если нужда появится.

Давай отложим.

Что мне сейчас посмотреть?