Л
Двойной или Н-ной смотря сколько интерфейсов
Size: a a a
2021 October 06
AD
как бы да - нельзя будет подписыватся одновременно на конкретное событие + интерфейс
Л
Насчет оверхеда согласен, я думаю если упрусь в это то соберу интерфейсы в компайл-тайме
AD
можно ещё покрутить, получится ли с алиасами выкрутится, как делали для BC в симфони
grep "event_dispatcher.event_aliases" в vendor и документации здесь https://symfony.com/doc/current/components/event_dispatcher.html
grep "event_dispatcher.event_aliases" в vendor и документации здесь https://symfony.com/doc/current/components/event_dispatcher.html
Л
Я думаю нужно расписать типичный пример проблемы. Есть фиче-модули которые делают что-то "полезное". Есть всякое инфра или чепуха типо лога для людей. Они хотят слушать сразу множество эвентов, но подписываться на каждый по отдельности я не хочу.
Кажется более логичным в фичемодуле в евент дописать реализацию интерфейса.
Еще сверху добавляется то что почти все фичемодули и инфрамодули опциональные.
Кажется более логичным в фичемодуле в евент дописать реализацию интерфейса.
Еще сверху добавляется то что почти все фичемодули и инфрамодули опциональные.
SP
"в ивент дописать реализацию интерфейса" - че?
Л
я думал потом в каждом модуле например добавить пасс автоконфига и сбор интерфейсов которые он слушает
Л
например "опиши себя человекочитаемо" или "что из тебя нужно кинуть в сокет"
SP
я просто свой ивент диспатчер сделал так как симфоневый мне не катит
SP
ивенты про это знать не должны, не надо путать ивенты (точки расширения) и команды (то что можно заменить вызовом метода, command patter)
МФ
а не, не я один
Л
а кто должен по твоему? я не особо спорю с этим т.к. не уврен в этом подходе
SP
никто не должен. у тебя есть ивент "что-то произошло" - тот кто ивент слушает решает что с ним надо делать
Л
ну тут поверх уже ряд кастомизаций, полностью отдельный пока был не нужен
МФ
давай по правильному — какую задачу решаешь?
Л
Тогда в горизонтальном модуле будет для сотни эвентов написано что с ними делать
Л
Т.е. как их описывать например
SP
а для "команд" когда "сообщение" знает что с ним будут делать - не еби голову и вызови метод, всякие эти штуки нужны только если "тот кто делает" живет в другом процессе и ты с ними очередями общаешься
Л
Может конечно так и удобнее
SP
да, для сотни ивентов будет написано что с ними делать. и это нормально. ну или у тебя "для сотни ивентов одинаково в лог вывести"? это декоратор над диспатчером может делать - ему не надо знать ничего про конкретные ивенты, будет выводить какие-то стандартные вещи вроде имени