На дворе 2017-ый год и довольно значительная часть сообщества PHP пытается использовать
PSR: PHP standard recommendation, цель которых — дать возможность заменять отдельные части фреймворков. Среди PSR-ов есть PSR-3, в котором описывается интерфейс для логгера. На данный момент существует множество совместимых с PSR-3 библиотек, в числе которых широко применяемый Monolog.
На тему PSR-3 и Yii 2.0 часто задают следующие вопросы:
- Почему Yii 2.0 не совместим с PSR-3?
- Как мне писать сообщения в совместимый с PSR-3 логгер?
- Есть ли в планах сделать логгер Yii совместимым с PSR-3 и выпилить в отдельный пакет?
Разберём каждый подробно.
Почему Yii 2.0 не совместим с PSR-3?
Логер в Yii 2.0 — один из добротно сделанных компонентов. Он стабилен, легко расширяется, работает быстро и умеет много всего. Разработан этот компонент был на ранних стадиях тогда ещё секретной пред-альфа версии фреймворка и с тех пор значительно не менялся. Дизайн очень близок к изначальному, который был в Yii 1.0, так что годом его формирования можно считать 2008.
Год важен, так как группа PHP-FIG, занимающаяся PSR-ами, сформировалась значительно позже. Во время альфа-версии Yii 2.0 у нас уже был проверенный рабочий дизайн логгера, отлично показавший себя на Yii 1.0 и Yii 1.1. В то время PSR-3 не был чем-то уж сильно привлекательным. Чего-то особенного логгеры, его реализующие, ещё не умели и, поэтому, плюсов в реализации этого PSR в Yii framework на тот момент не было. Решили не делать.
Сейчас пришло время рассмотреть решение ещё раз для версии 2.1 так как в совместимости с PSR-3 есть существенные плюсы.
Как мне писать сообщения в совместимый с PSR-3 логгер?
Логирование в Yii довольно гибко. Центральный компонент-диспетчер собирает сообщения и раскидывает их по индивидуальным целям логирования, которые, в свою очередь, пишут сообщения в файлы, отсылают почту и так далее.
Цели логирования легко расширять и создавать, так что написать свою не так уж сложно. С другой стороны, зачем что-то писать, когда есть популярные PSR-3 логгеры и, особенно,
Monolog? Так и хочется использовать готовое. Например, отсылать сообщения в чат Slack.
Я реализовал расширение, которое позволяет использовать любой совместимый PSR-3 логгер как цель логирования.
Расширение приводит уровни логирования Yii к сходным уровням PSR-3 и отдаёт сообщения и сопутствующие данные на обработку PSR-3 логеру. Конфигурация довольно проста и описана на странице расширения.
Есть ли в планах сделать логгер Yii совместимым с PSR-3 и выпилить в отдельный пакет?
Yii никогда не старался быть набором независимых библиотек. Независимые компоненты — штука хорошая, но у независимости есть цена. Приходится отказываться от переиспользования кода из ядра фреймворка, что выливается в довольно большой объём кода как такового и, зачастую, переабстрагированные решения.
Логгер, в принципе, не сильно относится к написанному выше. Он практически не зависит от фреймворка. Наоборот — фреймворк зависит от него. Попытка сделать из логгера отдельную библиотеку, возможно, удастся и так как дизайн довольно хорош, есть шанс получить своё место среди таких независимых решений, как Monolog. Стоит попробовать и я попробую, если кампания на Patreon даст мне достаточно времени для работы над OpenSource.
Комментарии (51)
dfuse
14.03.2017 02:32Независимые компоненты — штука хорошая, но у независимости есть цена. Приходится отказываться от переиспользования кода из ядра фреймворка, что выливается в довольно большой объём кода как такового и, зачастую, переабстрагированные решения.
А кто мешает ядро сделать тоже независимым компонентом? И переиспользовать его как угодно. В итоге получится эдакий шаг в сторону Zend Framework или Symfony.
Я ни в коем случае не агитирую немедленно так и поступить, Yii его монолитность даже на пользу, просто изначальное утверждение довольно спорное.
SamDark
14.03.2017 09:39Смотря что подразумевать под ядром. Тот же роутер сейчас — ядро, обработка ошибок — тоже.
dfuse
14.03.2017 09:50По логике — ядро = нечто неделимое, некая базовая единица функциональности (ядерную физику в расчет не берем). Роутер, по-идее — это уже не совсем ядро, приложение же может выжить без него, если оно консольное. А вот обработка ошибок — вполне.
В любом случае тут стоит подойти творчески и сбалансировать гранулярность, например, по принципам high cohesion и single responsibility (и другим подобным), чтобы вещи одной предметной области были в одном модуле, но без фанатизма, чтоб не пихать все подряд.
Если гранулярность довести до абсолюта, то получаются NPM пакеты
isNumberи так далее ;) а если наоборот — то Yii Framework.SamDark
14.03.2017 10:04+1А вот обработка ошибок — вполне.
Но это не вяжется с вытаскиванием библиотек. Потому что там, где их могут в теории использовать, своя обработка ошибок.
Если гранулярность довести до абсолюта, то получаются NPM пакеты
isNumberи так далее ;) а если наоборот — то Yii Framework.Ну не :) У нас всё-таки много уже разделено, просто основной пакет жирный и дополнительные вроде Redis зависят от него.
Mendel
14.03.2017 13:58Ну роутер то выносится без особых сложностей. Ну в том плане что он нужен только прикладным задачам и в принципе может быть заменен. Логер, обработка ошибок и т.п. — у всего есть более-менее формальные границы, где можно провести черту, и в крайнем случае подсунуть заглушку, сделать интерфейс (контракт) и т.п.
Но вот что делать с хардкорными зависимостями вроде завязки на DI, базовые классы тех же компонент, всякие ArrayHelper и прочие специфичные вещи? Ну если хелперы и прочее еще можно вынести в отдельные пакеты которые потом в зависимости засунуть, то что делать с самым ядерным API? Это переписывание всей архитектуры. Совсем всей. И да, увеличение объема кода как цена минимальной связности. Иначе если просто разобрать на части и прописать зависимости, то композер нам весь фреймворк и притянет.
Xu4
15.03.2017 16:58На дворе 2017-ый год и довольно значительная часть сообщества PHP пытается использовать
PSR: PHP standard recommendation, цель которых — дать возможность заменять отдельные части фреймворков.
Александр, я думаю, скорее всё дело в том, что вы участвуете в FIG, и у вас такое мнение из-за того, что этот котёл является частью вашей жизни.
Насколько я вижу из своего личного общения и из мыслей людей (а я всегда очень много и внимательно читаю чужое мнение на различных околопхпэшных ресурсах), люди начинают уставать от PSR из-за того, что стандарты PSR определяются один раз, и они развивают промышленность только в первое время. Однако, из-за подхода: «мы не будем ничего менять, потому что мы пять лет назад проголосовали за такой вариант (не будем вообще больше голосовать на эту тему)» — через какое-то время PSR начинает тормозить всё, а не помогать строить светлое будущее.
PSR, как бы, первое время помогает стать лучше, а потом, когда в PHP появляются какие-то изменения, PSR превращается в гирю на ноге, вместо того, чтобы быть двигателем.Mendel
15.03.2017 18:23Конкретные примеры можно?
Помню свой личный кейс, когда я ворчал по шорттегам, мол <?php прошлый век.
И СамДарк как раз мне и ответил что позиция тут в том, что <? всё еще можно отключить.
В принципе логично.
Опять таки — большинство стандартов это чисто стилистика, и определялась по принципу что выберем то и будет. Менять ее сейчас? Смысл? PSR созданы в первую очередь для единообразия.
Допускаю что я что-то пропустил, или вы говорите о тех стандартах которые не самые популярные, но хотелось бы примеров.Xu4
15.03.2017 18:35PSR созданы в первую очередь для единообразия
Как раз с единообразием есть кейс: Фигурные скобки в классах и функциях. До того, как в PHP появились анонимные классы и функции, фигурные скобки можно было нормально писать на следующей строке во всех ситуациях. Теперь же получается, что в определении класса в одной ситуации нужно писать их на той же строке, а в другой — на новой строке. Единообразие в подходе потрялось.
С одной стороны, люди понимают, что если эти скобки писать в анонимных классах и функциях с новой строки, уродуется код. Но вместо того, чтобы сделать единый подход, поменяв вообще стиль для любых классов и функций, сделали патч, который меняет подход в отдельных случаях, хотя можно было одним изменением решить эту проблему системно.
Если кто-то предлагает базовые вещи менять в стандарте, его отфутболивают (меня лично не отфутболивали, я просто уже долго наблюдаю за тем, как происходят обсуждения в FIG).
BoShurik
15.03.2017 19:02Большинство изначально использовало такой стиль, именно поэтому такой стиль используется в стандарте, а не наоборот.
Ну и вряд ли coding style можно назвать чем-то, что мешает "строить светлое будущее" :)Xu4
15.03.2017 19:37Я со своей колокольни вижу, что половина людей такой стиль использовало, а другая половина — нет (мне даже чаще встречался код, где скобки были на той же строке). А со своей колокольни я смотрю где-то с 2002-го года. Текущий стиль летом 2012-го (вместе с PSR-2) пришёл из проектов со знаменитыми именами. В этих проектах, в общем-то, было небольшое количество разработчиков (во всяком случае, точно было небольшое количество разработчиков, которые диктовали стиль кода всем остальным). По сути, текущий вариант пришёл из ограниченного количества проектов, которые были «на слуху». Всенародного голосования не было (за PSR-2 голосовало 18 человек: 13 — за, 4 — против, один — воздержался). Его и не могло быть, потому что FIG нужно было набрать авторитет за счёт причастности к крупным проектам. FIG в тот момент не было популярным. Всенародное голосование оно в тот момент не смогло бы устроить.
Если бы была возможность выяснить, как пишет большинство разработчкив, ещё неизвестно, что было бы в стандарте, потому что я чаще видел код, в котором фигурные скобки были на той же строке. Ну, просто, такой чаще встречался, чем код, где скобки шли на новой строке. Может быть, мне просто чаще такой код попадался, а на самом деле больше было кода, где скобки шли с новой строки. Лично я видел такую картину.BoShurik
15.03.2017 19:44Не всенародное, но голосование было (не путать с голосовавшими за стандарт):
http://www.php-fig.org/psr/psr-2/#appendix-a-survey
https://docs.google.com/spreadsheets/d/1b-wBdRi4j9bQWLi91r8hUMUoydQFA1LSmBbez1L4dVM/edit#gid=0Xu4
15.03.2017 19:53Ну, вы согласны, что стиль был взят из ограниченого количества проектов? Всенародного голосования не было. Учитывалась относительно небольшая база кода и мнение относительно небольшого количества разработчиков.
Вы писали, что «большинство изначально использовало такой стиль». Я с этим не согласен. Половина использовала один стиль, другая половина – другой. 50–100 разработчиков в крупных проектах — это не большинство программистов на тот момент.Mendel
16.03.2017 00:58«на тот момент» за пределами 50-100 разработчиков в крупных проектах — программистов в пхп и не было. Никого не хочу обидеть, но более-менее язык стал вырисовываться во что-то съедобное относительно недавно, и когда язык уже более-менее сформировался — еще экосистема отставала, а когда экосистема сформировалась — еще культуры не было.
Ее и сейчас не хватает, но раньше это кошмар был…
90% и сейчас говнокодеры, и их мнение по СТИЛЮ вообще не интересны.
Если мы сейчас начнем спрашивать стиль у всех, то мы получим смесь вордпрессовского кодекса с VQMOD (простите что помянул к ночи).
Вы хотите спрашивать мнение у людей использующих VQMOD? Вы хотите спрашивать мнение у людей которые способны использовать VQMOD? Вы хотите спрашивать мнение по стандартам оформления кода у людей которые знают что это такое, имели дело с VQMOD и способны говорить об этом без мата? Вы уверены?)
А ведь 90% сайтов, включая магазины сейчас делают на таких вещах или подобных вещах.
Вы не знаете что это и как оно работает?
Почитайте.
Там еще примеры есть, а то подозреваю без них многие решат что неправильно поняли что это и зачем).
Только на ночь не читайте.
И да, это не времена когда ООП в пхп был неработоспособным.
Вполне себе используется вместе с классами, даже «MVC».)))
И ведь это не пять строчек кода. Это кто-то соорудил, отладил, сотни разных модулей существуют работающих на этом идиотизме. Этот кошмар на гитхабе лежит, т.е. этот с позволения сказать «разработчик» даже гит использует. И да, у него есть какой-то стандарт кодирования. Его код даже можно читать. Мой код семилетней давности который до сих пор работает в некоторых проектах мне самому было читать много сложнее. Спросим у него как лучше оформлять код?)) Как именовать переменные, по сколько строк можно методы делать? Мне например тоже чисто визуально его оформление приятнее. Привычнее чтоли со времен когда я еще с пхп дела не имел. Но… может не надо?)Xu4
16.03.2017 01:05Если вы немного внимательнее почитаете мои комментарии, вы увидите, что я нигде не призывал к всенародному голосованию. Я только отметил факт, что его не было.
Mendel
16.03.2017 11:20Суть в том, что всенародных голосований не бывает в принципе.
Даже на выборах голосуют только дееспособные.
Причем по определенным ФОРМАЛЬНЫМ критериям.
Никому не проводят тесть Тьюринга на избирательном участке. (а жаль).
Возраст подходит? Справки о недееспособности нет? Пришел? Голосуй.
Так и здесь. Можешь участвовать в большом проекте? Пришел? Тебя посчитали).
Проголосовало «квалифицированное большинство». Не в том смысле в каком это словосочетание используют, а в значении дискриминации неквалифицированных)
BoShurik
16.03.2017 15:07Вот кстати статистика за 2013-2014 года. Думаю она актуальная в контексте нашей дискуссии. За это время PSR-2 не успел сильно распространиться
Xu4
17.03.2017 12:47А вы не обратили внимание, что там 64% — это открывающие скобки на той же строке для функций/методов? Получается противоречие с тем, что «Большинство изначально использовало такой стиль». А в случае с классами ситуация близка к 50/50.
BoShurik
17.03.2017 13:08Ну тут я солидарен с Mendel, не всех нужно спрашивать. К примеру, мало интересует стили кода у тех, кто пишет на Bitrix или WordPress, т.к. они эти стандарты не поддерживают, и сомневаюсь, что будут когда-то.
Xu4
17.03.2017 13:30Но вы же писали, что большинство так писало. Разве не так? Про то, что не нужно всех спрашивать — это уже другая опера. К тому же, если вы перечитаете мои комментарии, я нигде не утверждал, что нужно было спрашивать большинство. Я только озвучил факт, что всенародного голосования не было, и стиль брали из самых известных проектов, что на тот момент давало FIG политические очки.
BoShurik
17.03.2017 13:37Но вы же писали, что большинство так писало
Речь шла о "значимых" проектах, чьи участники принимали участие в формировании стандарта.
я нигде не утверждал, что нужно было спрашивать большинство. Я только озвучил факт, что всенародного голосования не было, и стиль брали из самых известных проектов, что на тот момент давало FIG политические очки.
И что тогда вы хотели этим сказать? :)
Xu4
17.03.2017 13:41Речь шла о «значимых» проектах, чьи участники принимали участие в формировании стандарта.
Если речь шла о значимых проектах, для чего вы кидали ссылку на http://sideeffect.kr/popularconvention#php в подтверждение ваших слов про «большинство»?
И что тогда вы хотели этим сказать? :)
Я хотел сказать, что из-за невнимательности люди начинают оспаривать слова, которые я не говорил. И этим тратят моё время впустую.
Xu4
15.03.2017 19:59Дополнительно, вы путаете статистическую выборку из 22-х баз кода с голосованием. Голосование — это когда отдельные люди высказывают мнение. Статистическая выборка — это когда у людей мнение не спрашивают, а просто анализируют что-то уже произошедшее.
На момент появления PSR-2 эти 22 проекта занимали крупную нишу во всех ±600 миллионах сайтов под PHP. Однако, если брать отдельных людей, которые в тот момент писали на PHP, их будет больше, чем количество людей, которые трудились над этими 22-мя проектами.
Понимаете мысль?Xu4
15.03.2017 20:08Поэтому нельзя сказать, что «большинство изначально использовало такой стиль», если в 16-ти из 22-х крупных проектов фигурные скобки после класса писались на следующей строке. Большинство крупных проектов не равно большинству людей — тех, кто вообще писал код на PHP в тот момент.
SamDark
15.03.2017 18:33+1Одни PSR способны заменять другие, как это произошло с PSR-0 и PSR-4 и как это, скорее всего, произойдёт с PSR-1, PSR-2 и PSR-12.
Xu4
15.03.2017 20:29По-моему, PSR-12 не упрощает некоторые вещи. И основная архитектурная проблема остаётся на месте: в одних случаях у функций и классов отрывающая фигурная скобка находится на той же самой строке, в других случаях — на следующей. Можно было бы сократить и упростить структуру стандарта, если бы фигурные скобки всегда писались на той же самой строке для классов и функций/методов — вне зависимости от того, анонимные они или нет.
SamDark
16.03.2017 00:32+1Случая всего два:
- Не анонимные классы и функции — следующая строка.
- Анонимные классы и функции — та же строка.
Кто пишет анонимки с открывающей скобкой на следующей строке — поднимите руки.
Xu4
16.03.2017 00:39Случая всего два
А мог бы быть один: «всегда та же строка». И это было бы проще, и было бы единообразие.
Кто пишет анонимки с открывающей скобкой на следующей строке — поднимите руки.
Добавьте это в стандарт и потихоньку все начнут писать так. Будет выглядеть некрасиво из-за контекста, в котором они обычно используются, но всё равно люди будут подтягиваться к стандарту.
Xu4
16.03.2017 00:40Я не спорю, на какой строке нужно писать скобки. Я просто обратил внимание, что PSR-12 не упрощает вещи, хотя мог бы.
BoShurik
16.03.2017 02:37+1Будет выглядеть некрасиво из-за контекста, в котором они обычно используются, но всё равно люди будут подтягиваться к стандарту.
Вы путаете с единообразием
PSR-12 не упрощает вещи, хотя мог бы.
Сделать стандартным правило расстановки скобок ? упростить. Текущая реализация вполне логична и делает проще чтение и изменение кода.
Логические конструкции и анонимные функции — на одной строке, чтобы код не разрастался по вертикали и его было удобнее читать.
Функции и классы — на новой строке, чтобы их описание не сливалось с кодом, что, опять же, упрощает чтение.
В случае с классами на одной строке с названием могут бытьextendsиimplements, которые удобнее добавлять в конце строке, а не кликать перед символом фигурной скобки.
И все-таки это ну никак не "архитектурная" проблема и, судя по приведенным вами примерам — единственная. Поэтому утверждение, что "через какое-то время PSR начинает тормозить всё, а не помогать строить светлое будущее" немного преувеличено :)
Xu4
16.03.2017 02:50Вы путаете с единообразием
Если не сложно, поясните, что именно я путаю с единообразием? Я не совсем понял. Я путаю «выглядеть некрасиво», или я путаю «к стандарту», или что-то ещё?
И все-таки это ну никак не «архитектурная» проблема
Мне кажется, она похожа на архитектурную проблему. Всё-таки эта проблема касается совокупности факторов. Если бы речь шла просто о том, что нужно или не нужно ставить скобки на отдельной строке, это была бы не архитектурная проблема. Но раз речь идёт о том, что можно единообразно относиться к похожим явлениям, и это единообразие поможет избавиться от избыточных описаний в стандарте, то это больше похоже на архитектурную проблему.SamDark
16.03.2017 14:23Задача стандарта кодирование не в том, чтобы сам стандарт был простым, а в том, чтобы писать и читать с этим стандартом было приятно и одинаково у всех.
Mendel
16.03.2017 01:05Я пишу открывающие скобки на той же строке. Что анонимные, что нет.
Исторически так сложилось. Вот как освою скрипты которые за меня оформление править будут, да доведу свой фреймворк до RC1 (точнее сначала доведу), тогда может начну переучиваться.
Так что да, если бы 12 делал бы на той же строке, то мне было бы удобно.
Но нет, я бы не проголосовал за такое изменение.
Пусть лучше гады переучиваются (и я в том числе), чем скакать туда-сюда.
Ведь в любом случае кто-то будет переучиваться. Или я, или тот парень, который уже научился под PSR.
Xu4
16.03.2017 22:17-1Вы, кстати, упустили ещё одну деталь. В первом варианте фигурная скобка иногда пишется на той же самой строке, что и закрывающая круглая для методов/функций (это есть и в PSR-2 и в PSR-12):
When the argument list is split across multiple lines, the closing parenthesis and opening brace MUST be placed together on their own line with one space between them.
Так что, случаев больше получается, чем два. А ведь можно было бы всё упростить, если, хотя бы для методов/функций, открывающая фигурная скобка писалась всегда на той же самой строке. Кучу «лишнего кода» ведь можно было бы тогда выкинуть из текста. :)BoShurik
17.03.2017 11:05Это описание стандарта. Важно чтобы при его прочтении не возникло недопонимания, поэтому текст бы никуда не делся, а просто заменили бы фразы "на следующей строке" \ "на этой же строке" на противоположные и все :)
Xu4
17.03.2017 12:43-1Вы, похоже, не до конца поняли ситуацию и не видите, что после этого возникнет дублирование инфромации, которое можно будет безболезненно удалить из текста, упрощая его. :)
BoShurik
17.03.2017 13:02http://www.php-fig.org/psr/psr-2/#overview
Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.На лицо дублирование, но почему-то никто не объединил эти два пункта ;)
Один пункт — одно утверждениеXu4
17.03.2017 13:32-1То есть, до конца вы разобрать ситуацию так и не захотели, я правильно понимаю?
lllypynby
А есть планы по выносу AR из ядра? Мне очень нравится ишная реализация, тот же laravel на порядок хуже, а больше вариантов то и нет.
SamDark
Мы думали над этим, не против запилить, но дело не простое и уж точно не приоритетное.
Mendel
А его вообще можно отвязать от DAO построителей и т.п.?
ИМХО это будет или прогнуться под чужой стандарт или тащить с собой кучу подсистем.
И это помимо того что надо отдирать связность с ядром, хелперами, DI и т.п.
А всё это без заметного изменения АПИ сделать будет едва ли возможно.
Признаться в коде Yii особо не копался, но по опыту кажется что будет ахтунг.
У логеров хоть стандарт есть (PSR-3) и то работа будет не то чтобы элементарная.
SamDark
AR написан поверх Query Builder и именно за счёт него такой гибкий и приятный. Если вытаскивать, то вместе с DAO.
dfuse
В Yii, кроме перечисленных, еще очень много того, что можно бы вытащить как библиотеку.
SamDark
Согласен.