Yii 3 и PSR
21 августа 2021
На хабре задали интересный вопрос: «зачем пилить свои имплементации шаблонных вещей когда вокруг куча готовых, протестированных, оптимизированных? Не является ли это бутылочным горлышком в процессе реализации фреймворка?»
Распишу по каждому PSR-у:
- 1 - Basic Conding Standard. Исплользуем, не переделывали.
- 3 - Logger Interface. Можно было взять Monolog, но нам нравился концепт логгера из Yii 2 больше, поэтому портировали и почистили. Но можно использовать в своих приложениях и Monolog.
- 4 - Autoloading Standard. Исплользуем, не переделывали.
- 6 - Caching Interface. Не используем, см. 16.
- 7 - HTTP Message Interface. Своё сразу решили не делать. Сначала сравнили всё и выбрали самую лёгкую реализацию Tobias Nyholm. Но потом пришёл Евгений, у которого была ещё более оптимальная реализация. Впоследствии он влился в команду фреймворка.
- 11 - Container Interface. Контейнер свой потому как стандарт регламентирует только получение зависимостей, а конфигурирование — нет. Сделать удобное конфигруирование как раз задача для фреймворка и то, что его отличает от других. И да, вот эта реализация кушает много времени.
- 12 - Extended Coding Style Guide. Этот стандарт я координировал в PHP-FIG. Конечно же, используем.
- 13 - Hypermedia Links. Не используем.
- 14 - Event Dispatcher. Написали свой, ничего достойного готового на момент выхода стандарта не было, а события уже были нужны.
- 15 - HTTP Handlers. Тоже центральная часть фреймворка так как определяет, какие Middleware поддерживаются, как задаются и, главное, как вызываются. Поэтому написали свой.
- 16 - Simple Cache. Написали не PSR-ный yiisoft/cache, который использует любые PSR-16 адаптеры кеша и добавляет сверху всякие классные штуки. Ну а так как с Yii 2 уже был рабочий код адаптеров, портировали в PSR-16.
- 17 - HTTP Factories. См. 7.
- 18 - HTTP Client. Не будем реализовывать, будем использовать.
Каждый из пакетов мы покрываем очень хорошо тестами, поэтому после начального релиза сильной поддержки PSR-пакет с фиксированными требованиями не требует.
Комментарии RSS по email OK
Одно другому не мешает. У того же symfony cache 2 интерфейса. Один psr, другой свой с плюшками.
hardworm, примерно так, да. Оба PSR-совместимые, пользователь может выбрать. В приложении ничего не поменяется.
Александр, он другой и там прилично всего именно под остальные компоненты Symfony заточено: compiler pass-ы, свои интерфейсы, необходимость наслеоваться от
Symfony\Contracts\EventDispatcher\Event
, мутабельность по дефолту. А ещё на момент выхода PSR-14 диспетчер Symfony его не реализовывал.Sam, да, там есть несколько классов, для интеграции с фреймворком, но это же не мешает использовать его отдельно. Это как если бы никто не станет использовать новые компоненты yii потому что там присутствует папочка config с дефинишенами для контейнера :) Свой интерфейс нужен, если нужны доп. фишки, которых нет в PSR-реализации (возможность передать имя эвента напрямую). Опят же это тоже не должно мешать. Базовый класс имплементит StoppableEventInterface от него наследоваться не обязательно. Ну и мутабельность - это вопрос клиентского кода, а не библиотеки
Александр, ну так-то да, не критичные штуки. Просто PSR-интерфейса там на тот момент, насколько я помню, не было.