Они покрыли кейсы стандартных event диспетчеров, что уже есть и применяются везде. И эти существующие решения уже привили, что их ивенты, это больше как хуки, чем true-события.

https://www.php-fig.org/psr/psr-14/meta/#43-immutable-events

поэтому если бы они сделали "true"-события, их бы никто не брал, т. к. все привыкли к хукам

стандарт psr7 вважаю важливим, але от так як він зараз існує не класно. У сімфоні він не підтримується і це печаль. Робота з http взагалі ключова при розробці у вебі.

Я не сильно понял, зачем Симфони сделали ещё один Guzzle. Может кто-то объяснить?)

Потому что могут)

потому что потом можно требовать денежку за саппорт, а обычным юзерам apt install symfony и все из коробки работает

NIH :)

У меня вот больше всего подгорает не из за самого стандарта ( считаю его полезным), а из-за нейминга. Назвалибы его hooks и не вводили людей в заблуждение.

А як назвали?

event dispatcher

Ивенты с isPropagationStopped...

Думаю, брали отсюда https://api.jquery.com/event.isPropagationStopped/

в webapi также есть возможность остановить обработку

Ладно, похейтили и хватит) Справедливости ради:

1. isPropagationStopped вынесен в отдельный интерфейс и его использовать не обязательно
2. Стандарт не регламентирует и не ограничнивеа реализацию самих объектов событий. Если нужна иммутабельность – делай иммутабельные объекты событий.
3. API достаточно универсальный, чтобы использовать его как для хуков, так и для доменных событий.
4. Стандарт не конфликтует с тем, как ивенты повсеместно используются в реальной жизни.

Что ещё не так?)

ой всё

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

Ладно, есть к чему докопатся :)

https://github.com/php-fig/event-dispatcher/blob/master/src/EventDispatcherInterface.php#L18

> Ладно, есть к чему докопатся 🙂

Ну так это как раз признак универсальности API. Если у тебя объект изменяемый – получишь изменённый объект. Если нет – то нет 🙂

Я тут со своей больной фантазией только что придумал что-то типа MiddlewareDispatcher поверх иммутабельных объектов событий.
Каждый слушатель может вернуть форк объекта события, который будет передан следующим слушателями вместо изначального. Последний вариант события будет возвращён из метода Dispatch