Диспетчер событий с фильтрацией по шаблону

[@hell0w0rd]

Странный метод на мой взгляд. Гораздо понятнее создать объект Event, в который будет добавляться информация о эвенте, что у вас уже реализовано:

$dispatcher->trigger('children.said_somth');
$dispatcher->trigger('children.said_somth', 'Bobby');

[@PopeyetheSailor]

А мне понравилось. Можно крутить как хочешь

$dispatcher->trigger('**.said_somth');
$dispatcher->trigger('children.**');
$dispatcher->trigger('children.Bobby.*');

[@hell0w0rd]

мне не нравится идея связывать название события с данными о событии. Событие должно быть одно, а данные его породившие могут отличаться.
Если перенести это на js, то зачем вам такое:

on('mouse_move.*.*', function (x, y){log([x, y])})

Если можно сделать так:

on('mouse_move', function (e){log([e.x, e.y])})

[@balkon_smoke]

В JS объект события тянет с собой информацию о контексте: тип события, объект, с которым событие произошло, время и кучу других характеристик. Здесь, конечно, мы получим полотно длинною в жизнь, если развернем параметры в формальные переменные.

От eventable не требуется знать все (или достаточно много) о контексте выполнения. Достаточно знать, что событие произошло и пора что-то с этим делать. Но в планах есть добавление сущности Event, которая будет переносить в себе и пользовательские данные, и служебные.

[@hell0w0rd]

У вас и так это есть. Просто может я не до конца вас понял — в каких кейсах может понадобится динамичное название события? Событие одно и то же все время, просто данные к нему биндятся разные.

[@AterCattus]

Автор перенес часть данных о событии в название события. Видимо такое понадобилось или захотелось.

[@AterCattus]

Стоило ли разделять два столь похожих метода fire и trigger? Обойтись бы одним.

И у вас в коде то [^\.], то просто [^.]. Это вы специально слеш обрабатываете, или это ошибочное экранирование?