Тимлид хороший вышел. Вероятно, нашёл в команду профессиональных писателей доков. Но это пока не точно.

Ок, как посмотришь пр в фастроуте, отпишешься, я опишу вкратце суть дальнейших изменений.

Хорошо.

@yiiliveext посмотрел. Есть концептуальные вопросы.

Ответил на некоторые. Сейчас напишу суть дальнейших изменений и остальные вопросы отпадут.

Хорошо.

В общем и целом идея с неким сборным интерфейсом для роутера была сама по себе неплохая. Но реализация ее была выбрана не оптимальная. Для этих целей гораздо лучше походит композиция, чем наследование. Поэтому я хочу вынести матчер в отдельный класс, так же как сделал это с генератором. Сам класс FastRoute будет композиций этих двух классов и проксировать методы match, generate, generateAbsolute. Кроме них, он будет принимать в конструкторе некий новый класс RouteCollection, который будет представлять собой ридонли коллекцию роутов, в нем же будет происходить сборка групп и роутов с коллектора в массив routes, который сейчас есть и в генераторе и в роутуре/матчере. Соответсвенно метода injectItems В генераторе не будет, а в конструкторе он будет принимать этот самый RouteCollection. То же самое будет в матчере, но там будут добавляться только сами роуты и группы уже в сам фастроут. Сам RouteCollection будет формироваться в AppRouterFactory. В основном конфиге к интерфейсу коллектора будет забиндена пустая корневая группа (new Group()). Все middleware до роутера смогут добавлять туда свои роуты/группы (например, в моем случае это автозагрузчик модулей, который будет добавлять роуты из конфига модулей). Потом в AppRouterFactory в коллектор будут добавляться роуты самого приложения и он будет передаваться в RouteCollection.  Вкратце как-то так.

и получится предыдущая версия только с бОльшим количеством классов?
здесь проблема такая, что нужно вынести коллектор отдельно. роутер будет принимать его как зависимость, генератор тоже

Ты точно внимательно читал то, что я написал?

а, видимо я не о том. думал про одно, написал про другое)

> Сам класс FastRoute будет композиций этих двух классов и проксировать методы match, generate, generateAbsolute.
тут не понял прикола

Что тебя удивляет? Обычная композиция. Матчер и генератор в приватных переменных, метод матч роутера вызывает метод матч матчера, с генератором аналогично. Если нам нужен только матчер, то мы запрашиваем из контейнера его интерфейс и нам прилетает конкретно матчер, а не весь роутер, как сейчас, когда мы матчером можем генерить роуты. Если нужен только генератор - запрашиваем его интерфейс и прилетит чисто генератор. Если нужно все в комплексе - запрашиваем интерфейс роутера, в котором есть и мачер и генератор (как сейчас в мастере).

> (как сейчас в мастере).

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

Сейчас я могу сделать так

public function someAction(UrlMatcherIterface $matcher)
{
    $path = $matcher->generate('blog-post/index');
}

Или ты не согласен с SRP?

srp?

PSR?

тоже не понятно, причём тут PRS

ходовая аббревиатура?

У кого как