<rmcreative>

RSS

Yii 3 и PSR

21 августа

На хабре задали интересный вопрос: «зачем пилить свои имплементации шаблонных вещей когда вокруг куча готовых, протестированных, оптимизированных? Не является ли это бутылочным горлышком в процессе реализации фреймворка?»

Распишу по каждому 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

  1. №12226
    hardworm
    hardworm 22 авг. 2021 г., 16:58:51

    Logger Interface. Можно было взять Monolog, но нам нравился концепт логгера из Yii 2 больше

    Одно другому не мешает. У того же symfony cache 2 интерфейса. Один psr, другой свой с плюшками.

  2. №12227
    Александр
    Александр 22 авг. 2021 г., 19:21:35
    1. А как же github.com/symfony/event-dispatcher ? Тем более что он и так идет вслед за console
  3. №12228
    Sam
    Sam 23 авг. 2021 г., 15:57:05

    hardworm, примерно так, да. Оба PSR-совместимые, пользователь может выбрать. В приложении ничего не поменяется.

    Александр, он другой и там прилично всего именно под остальные компоненты Symfony заточено: compiler pass-ы, свои интерфейсы, необходимость наслеоваться от Symfony\Contracts\EventDispatcher\Event, мутабельность по дефолту. А ещё на момент выхода PSR-14 диспетчер Symfony его не реализовывал.

  4. №12229
    Александр
    Александр 23 авг. 2021 г., 16:28:32

    Sam, да, там есть несколько классов, для интеграции с фреймворком, но это же не мешает использовать его отдельно. Это как если бы никто не станет использовать новые компоненты yii потому что там присутствует папочка config с дефинишенами для контейнера :) Свой интерфейс нужен, если нужны доп. фишки, которых нет в PSR-реализации (возможность передать имя эвента напрямую). Опят же это тоже не должно мешать. Базовый класс имплементит StoppableEventInterface от него наследоваться не обязательно. Ну и мутабельность - это вопрос клиентского кода, а не библиотеки

  5. №12230
    Sam
    Sam 24 авг. 2021 г., 1:05:25

    Александр, ну так-то да, не критичные штуки. Просто PSR-интерфейса там на тот момент, насколько я помню, не было.

  1. Почта опубликована не будет.

  2. Можно использовать синтаксис Markdown или HTML.

  3. Введите ответ в поле. Щёлкните, чтобы получить другую задачу.