Comments 51
А есть планы по выносу AR из ядра? Мне очень нравится ишная реализация, тот же laravel на порядок хуже, а больше вариантов то и нет.
Мы думали над этим, не против запилить, но дело не простое и уж точно не приоритетное.
А его вообще можно отвязать от DAO построителей и т.п.?
ИМХО это будет или прогнуться под чужой стандарт или тащить с собой кучу подсистем.
И это помимо того что надо отдирать связность с ядром, хелперами, DI и т.п.
А всё это без заметного изменения АПИ сделать будет едва ли возможно.
Признаться в коде Yii особо не копался, но по опыту кажется что будет ахтунг.
У логеров хоть стандарт есть (PSR-3) и то работа будет не то чтобы элементарная.
ИМХО это будет или прогнуться под чужой стандарт или тащить с собой кучу подсистем.
И это помимо того что надо отдирать связность с ядром, хелперами, DI и т.п.
А всё это без заметного изменения АПИ сделать будет едва ли возможно.
Признаться в коде Yii особо не копался, но по опыту кажется что будет ахтунг.
У логеров хоть стандарт есть (PSR-3) и то работа будет не то чтобы элементарная.
Независимые компоненты — штука хорошая, но у независимости есть цена. Приходится отказываться от переиспользования кода из ядра фреймворка, что выливается в довольно большой объём кода как такового и, зачастую, переабстрагированные решения.
А кто мешает ядро сделать тоже независимым компонентом? И переиспользовать его как угодно. В итоге получится эдакий шаг в сторону Zend Framework или Symfony.
Я ни в коем случае не агитирую немедленно так и поступить, Yii его монолитность даже на пользу, просто изначальное утверждение довольно спорное.
Смотря что подразумевать под ядром. Тот же роутер сейчас — ядро, обработка ошибок — тоже.
По логике — ядро = нечто неделимое, некая базовая единица функциональности (ядерную физику в расчет не берем). Роутер, по-идее — это уже не совсем ядро, приложение же может выжить без него, если оно консольное. А вот обработка ошибок — вполне.
В любом случае тут стоит подойти творчески и сбалансировать гранулярность, например, по принципам high cohesion и single responsibility (и другим подобным), чтобы вещи одной предметной области были в одном модуле, но без фанатизма, чтоб не пихать все подряд.
Если гранулярность довести до абсолюта, то получаются NPM пакеты isNumber и так далее ;) а если наоборот — то Yii Framework.
А вот обработка ошибок — вполне.
Но это не вяжется с вытаскиванием библиотек. Потому что там, где их могут в теории использовать, своя обработка ошибок.
Если гранулярность довести до абсолюта, то получаются NPM пакеты isNumber и так далее ;) а если наоборот — то Yii Framework.Ну не :) У нас всё-таки много уже разделено, просто основной пакет жирный и дополнительные вроде Redis зависят от него.
Ну роутер то выносится без особых сложностей. Ну в том плане что он нужен только прикладным задачам и в принципе может быть заменен. Логер, обработка ошибок и т.п. — у всего есть более-менее формальные границы, где можно провести черту, и в крайнем случае подсунуть заглушку, сделать интерфейс (контракт) и т.п.
Но вот что делать с хардкорными зависимостями вроде завязки на DI, базовые классы тех же компонент, всякие ArrayHelper и прочие специфичные вещи? Ну если хелперы и прочее еще можно вынести в отдельные пакеты которые потом в зависимости засунуть, то что делать с самым ядерным API? Это переписывание всей архитектуры. Совсем всей. И да, увеличение объема кода как цена минимальной связности. Иначе если просто разобрать на части и прописать зависимости, то композер нам весь фреймворк и притянет.
Но вот что делать с хардкорными зависимостями вроде завязки на DI, базовые классы тех же компонент, всякие ArrayHelper и прочие специфичные вещи? Ну если хелперы и прочее еще можно вынести в отдельные пакеты которые потом в зависимости засунуть, то что делать с самым ядерным API? Это переписывание всей архитектуры. Совсем всей. И да, увеличение объема кода как цена минимальной связности. Иначе если просто разобрать на части и прописать зависимости, то композер нам весь фреймворк и притянет.
На дворе 2017-ый год и довольно значительная часть сообщества PHP пытается использовать
PSR: PHP standard recommendation, цель которых — дать возможность заменять отдельные части фреймворков.
Александр, я думаю, скорее всё дело в том, что вы участвуете в FIG, и у вас такое мнение из-за того, что этот котёл является частью вашей жизни.
Насколько я вижу из своего личного общения и из мыслей людей (а я всегда очень много и внимательно читаю чужое мнение на различных околопхпэшных ресурсах), люди начинают уставать от PSR из-за того, что стандарты PSR определяются один раз, и они развивают промышленность только в первое время. Однако, из-за подхода: «мы не будем ничего менять, потому что мы пять лет назад проголосовали за такой вариант (не будем вообще больше голосовать на эту тему)» — через какое-то время PSR начинает тормозить всё, а не помогать строить светлое будущее.
PSR, как бы, первое время помогает стать лучше, а потом, когда в PHP появляются какие-то изменения, PSR превращается в гирю на ноге, вместо того, чтобы быть двигателем.
Конкретные примеры можно?
Помню свой личный кейс, когда я ворчал по шорттегам, мол <?php прошлый век.
И СамДарк как раз мне и ответил что позиция тут в том, что <? всё еще можно отключить.
В принципе логично.
Опять таки — большинство стандартов это чисто стилистика, и определялась по принципу что выберем то и будет. Менять ее сейчас? Смысл? PSR созданы в первую очередь для единообразия.
Допускаю что я что-то пропустил, или вы говорите о тех стандартах которые не самые популярные, но хотелось бы примеров.
Помню свой личный кейс, когда я ворчал по шорттегам, мол <?php прошлый век.
И СамДарк как раз мне и ответил что позиция тут в том, что <? всё еще можно отключить.
В принципе логично.
Опять таки — большинство стандартов это чисто стилистика, и определялась по принципу что выберем то и будет. Менять ее сейчас? Смысл? PSR созданы в первую очередь для единообразия.
Допускаю что я что-то пропустил, или вы говорите о тех стандартах которые не самые популярные, но хотелось бы примеров.
PSR созданы в первую очередь для единообразия
Как раз с единообразием есть кейс: Фигурные скобки в классах и функциях. До того, как в PHP появились анонимные классы и функции, фигурные скобки можно было нормально писать на следующей строке во всех ситуациях. Теперь же получается, что в определении класса в одной ситуации нужно писать их на той же строке, а в другой — на новой строке. Единообразие в подходе потрялось.
С одной стороны, люди понимают, что если эти скобки писать в анонимных классах и функциях с новой строки, уродуется код. Но вместо того, чтобы сделать единый подход, поменяв вообще стиль для любых классов и функций, сделали патч, который меняет подход в отдельных случаях, хотя можно было одним изменением решить эту проблему системно.
Если кто-то предлагает базовые вещи менять в стандарте, его отфутболивают (меня лично не отфутболивали, я просто уже долго наблюдаю за тем, как происходят обсуждения в FIG).
Большинство изначально использовало такой стиль, именно поэтому такой стиль используется в стандарте, а не наоборот.
Ну и вряд ли coding style можно назвать чем-то, что мешает "строить светлое будущее" :)
Я со своей колокольни вижу, что половина людей такой стиль использовало, а другая половина — нет (мне даже чаще встречался код, где скобки были на той же строке). А со своей колокольни я смотрю где-то с 2002-го года. Текущий стиль летом 2012-го (вместе с PSR-2) пришёл из проектов со знаменитыми именами. В этих проектах, в общем-то, было небольшое количество разработчиков (во всяком случае, точно было небольшое количество разработчиков, которые диктовали стиль кода всем остальным). По сути, текущий вариант пришёл из ограниченного количества проектов, которые были «на слуху». Всенародного голосования не было (за PSR-2 голосовало 18 человек: 13 — за, 4 — против, один — воздержался). Его и не могло быть, потому что FIG нужно было набрать авторитет за счёт причастности к крупным проектам. FIG в тот момент не было популярным. Всенародное голосование оно в тот момент не смогло бы устроить.
Если бы была возможность выяснить, как пишет большинство разработчкив, ещё неизвестно, что было бы в стандарте, потому что я чаще видел код, в котором фигурные скобки были на той же строке. Ну, просто, такой чаще встречался, чем код, где скобки шли на новой строке. Может быть, мне просто чаще такой код попадался, а на самом деле больше было кода, где скобки шли с новой строки. Лично я видел такую картину.
Если бы была возможность выяснить, как пишет большинство разработчкив, ещё неизвестно, что было бы в стандарте, потому что я чаще видел код, в котором фигурные скобки были на той же строке. Ну, просто, такой чаще встречался, чем код, где скобки шли на новой строке. Может быть, мне просто чаще такой код попадался, а на самом деле больше было кода, где скобки шли с новой строки. Лично я видел такую картину.
Не всенародное, но голосование было (не путать с голосовавшими за стандарт):
http://www.php-fig.org/psr/psr-2/#appendix-a-survey
https://docs.google.com/spreadsheets/d/1b-wBdRi4j9bQWLi91r8hUMUoydQFA1LSmBbez1L4dVM/edit#gid=0
Ну, вы согласны, что стиль был взят из ограниченого количества проектов? Всенародного голосования не было. Учитывалась относительно небольшая база кода и мнение относительно небольшого количества разработчиков.
Вы писали, что «большинство изначально использовало такой стиль». Я с этим не согласен. Половина использовала один стиль, другая половина – другой. 50–100 разработчиков в крупных проектах — это не большинство программистов на тот момент.
Вы писали, что «большинство изначально использовало такой стиль». Я с этим не согласен. Половина использовала один стиль, другая половина – другой. 50–100 разработчиков в крупных проектах — это не большинство программистов на тот момент.
«на тот момент» за пределами 50-100 разработчиков в крупных проектах — программистов в пхп и не было. Никого не хочу обидеть, но более-менее язык стал вырисовываться во что-то съедобное относительно недавно, и когда язык уже более-менее сформировался — еще экосистема отставала, а когда экосистема сформировалась — еще культуры не было.
Ее и сейчас не хватает, но раньше это кошмар был…
90% и сейчас говнокодеры, и их мнение по СТИЛЮ вообще не интересны.
Если мы сейчас начнем спрашивать стиль у всех, то мы получим смесь вордпрессовского кодекса с VQMOD (простите что помянул к ночи).
Вы хотите спрашивать мнение у людей использующих VQMOD? Вы хотите спрашивать мнение у людей которые способны использовать VQMOD? Вы хотите спрашивать мнение по стандартам оформления кода у людей которые знают что это такое, имели дело с VQMOD и способны говорить об этом без мата? Вы уверены?)
А ведь 90% сайтов, включая магазины сейчас делают на таких вещах или подобных вещах.
Вы не знаете что это и как оно работает?
Почитайте.
Там еще примеры есть, а то подозреваю без них многие решат что неправильно поняли что это и зачем).
Только на ночь не читайте.
И да, это не времена когда ООП в пхп был неработоспособным.
Вполне себе используется вместе с классами, даже «MVC».)))
И ведь это не пять строчек кода. Это кто-то соорудил, отладил, сотни разных модулей существуют работающих на этом идиотизме. Этот кошмар на гитхабе лежит, т.е. этот с позволения сказать «разработчик» даже гит использует. И да, у него есть какой-то стандарт кодирования. Его код даже можно читать. Мой код семилетней давности который до сих пор работает в некоторых проектах мне самому было читать много сложнее. Спросим у него как лучше оформлять код?)) Как именовать переменные, по сколько строк можно методы делать? Мне например тоже чисто визуально его оформление приятнее. Привычнее чтоли со времен когда я еще с пхп дела не имел. Но… может не надо?)
Ее и сейчас не хватает, но раньше это кошмар был…
90% и сейчас говнокодеры, и их мнение по СТИЛЮ вообще не интересны.
Если мы сейчас начнем спрашивать стиль у всех, то мы получим смесь вордпрессовского кодекса с VQMOD (простите что помянул к ночи).
Вы хотите спрашивать мнение у людей использующих VQMOD? Вы хотите спрашивать мнение у людей которые способны использовать VQMOD? Вы хотите спрашивать мнение по стандартам оформления кода у людей которые знают что это такое, имели дело с VQMOD и способны говорить об этом без мата? Вы уверены?)
А ведь 90% сайтов, включая магазины сейчас делают на таких вещах или подобных вещах.
Вы не знаете что это и как оно работает?
Почитайте.
Там еще примеры есть, а то подозреваю без них многие решат что неправильно поняли что это и зачем).
Только на ночь не читайте.
И да, это не времена когда ООП в пхп был неработоспособным.
Вполне себе используется вместе с классами, даже «MVC».)))
И ведь это не пять строчек кода. Это кто-то соорудил, отладил, сотни разных модулей существуют работающих на этом идиотизме. Этот кошмар на гитхабе лежит, т.е. этот с позволения сказать «разработчик» даже гит использует. И да, у него есть какой-то стандарт кодирования. Его код даже можно читать. Мой код семилетней давности который до сих пор работает в некоторых проектах мне самому было читать много сложнее. Спросим у него как лучше оформлять код?)) Как именовать переменные, по сколько строк можно методы делать? Мне например тоже чисто визуально его оформление приятнее. Привычнее чтоли со времен когда я еще с пхп дела не имел. Но… может не надо?)
Если вы немного внимательнее почитаете мои комментарии, вы увидите, что я нигде не призывал к всенародному голосованию. Я только отметил факт, что его не было.
Суть в том, что всенародных голосований не бывает в принципе.
Даже на выборах голосуют только дееспособные.
Причем по определенным ФОРМАЛЬНЫМ критериям.
Никому не проводят тесть Тьюринга на избирательном участке. (а жаль).
Возраст подходит? Справки о недееспособности нет? Пришел? Голосуй.
Так и здесь. Можешь участвовать в большом проекте? Пришел? Тебя посчитали).
Проголосовало «квалифицированное большинство». Не в том смысле в каком это словосочетание используют, а в значении дискриминации неквалифицированных)
Даже на выборах голосуют только дееспособные.
Причем по определенным ФОРМАЛЬНЫМ критериям.
Никому не проводят тесть Тьюринга на избирательном участке. (а жаль).
Возраст подходит? Справки о недееспособности нет? Пришел? Голосуй.
Так и здесь. Можешь участвовать в большом проекте? Пришел? Тебя посчитали).
Проголосовало «квалифицированное большинство». Не в том смысле в каком это словосочетание используют, а в значении дискриминации неквалифицированных)
Вот кстати статистика за 2013-2014 года. Думаю она актуальная в контексте нашей дискуссии. За это время PSR-2 не успел сильно распространиться
А вы не обратили внимание, что там 64% — это открывающие скобки на той же строке для функций/методов? Получается противоречие с тем, что «Большинство изначально использовало такой стиль». А в случае с классами ситуация близка к 50/50.
Ну тут я солидарен с Mendel, не всех нужно спрашивать. К примеру, мало интересует стили кода у тех, кто пишет на Bitrix или WordPress, т.к. они эти стандарты не поддерживают, и сомневаюсь, что будут когда-то.
Но вы же писали, что большинство так писало. Разве не так? Про то, что не нужно всех спрашивать — это уже другая опера. К тому же, если вы перечитаете мои комментарии, я нигде не утверждал, что нужно было спрашивать большинство. Я только озвучил факт, что всенародного голосования не было, и стиль брали из самых известных проектов, что на тот момент давало FIG политические очки.
Но вы же писали, что большинство так писало
Речь шла о "значимых" проектах, чьи участники принимали участие в формировании стандарта.
я нигде не утверждал, что нужно было спрашивать большинство. Я только озвучил факт, что всенародного голосования не было, и стиль брали из самых известных проектов, что на тот момент давало FIG политические очки.
И что тогда вы хотели этим сказать? :)
Речь шла о «значимых» проектах, чьи участники принимали участие в формировании стандарта.
Если речь шла о значимых проектах, для чего вы кидали ссылку на http://sideeffect.kr/popularconvention#php в подтверждение ваших слов про «большинство»?
И что тогда вы хотели этим сказать? :)
Я хотел сказать, что из-за невнимательности люди начинают оспаривать слова, которые я не говорил. И этим тратят моё время впустую.
Дополнительно, вы путаете статистическую выборку из 22-х баз кода с голосованием. Голосование — это когда отдельные люди высказывают мнение. Статистическая выборка — это когда у людей мнение не спрашивают, а просто анализируют что-то уже произошедшее.
На момент появления PSR-2 эти 22 проекта занимали крупную нишу во всех ±600 миллионах сайтов под PHP. Однако, если брать отдельных людей, которые в тот момент писали на PHP, их будет больше, чем количество людей, которые трудились над этими 22-мя проектами.
Понимаете мысль?
На момент появления PSR-2 эти 22 проекта занимали крупную нишу во всех ±600 миллионах сайтов под PHP. Однако, если брать отдельных людей, которые в тот момент писали на PHP, их будет больше, чем количество людей, которые трудились над этими 22-мя проектами.
Понимаете мысль?
Одни PSR способны заменять другие, как это произошло с PSR-0 и PSR-4 и как это, скорее всего, произойдёт с PSR-1, PSR-2 и PSR-12.
А какой у него статус кстати? драфт?
По-моему, PSR-12 не упрощает некоторые вещи. И основная архитектурная проблема остаётся на месте: в одних случаях у функций и классов отрывающая фигурная скобка находится на той же самой строке, в других случаях — на следующей. Можно было бы сократить и упростить структуру стандарта, если бы фигурные скобки всегда писались на той же самой строке для классов и функций/методов — вне зависимости от того, анонимные они или нет.
Случая всего два:
- Не анонимные классы и функции — следующая строка.
- Анонимные классы и функции — та же строка.
Кто пишет анонимки с открывающей скобкой на следующей строке — поднимите руки.
Случая всего два
А мог бы быть один: «всегда та же строка». И это было бы проще, и было бы единообразие.
Кто пишет анонимки с открывающей скобкой на следующей строке — поднимите руки.
Добавьте это в стандарт и потихоньку все начнут писать так. Будет выглядеть некрасиво из-за контекста, в котором они обычно используются, но всё равно люди будут подтягиваться к стандарту.
Я не спорю, на какой строке нужно писать скобки. Я просто обратил внимание, что PSR-12 не упрощает вещи, хотя мог бы.
Будет выглядеть некрасиво из-за контекста, в котором они обычно используются, но всё равно люди будут подтягиваться к стандарту.
Вы путаете с единообразием
PSR-12 не упрощает вещи, хотя мог бы.
Сделать стандартным правило расстановки скобок ≠ упростить. Текущая реализация вполне логична и делает проще чтение и изменение кода.
Логические конструкции и анонимные функции — на одной строке, чтобы код не разрастался по вертикали и его было удобнее читать.
Функции и классы — на новой строке, чтобы их описание не сливалось с кодом, что, опять же, упрощает чтение.
В случае с классами на одной строке с названием могут быть extends и implements, которые удобнее добавлять в конце строке, а не кликать перед символом фигурной скобки.
И все-таки это ну никак не "архитектурная" проблема и, судя по приведенным вами примерам — единственная. Поэтому утверждение, что "через какое-то время PSR начинает тормозить всё, а не помогать строить светлое будущее" немного преувеличено :)
Вы путаете с единообразием
Если не сложно, поясните, что именно я путаю с единообразием? Я не совсем понял. Я путаю «выглядеть некрасиво», или я путаю «к стандарту», или что-то ещё?
И все-таки это ну никак не «архитектурная» проблема
Мне кажется, она похожа на архитектурную проблему. Всё-таки эта проблема касается совокупности факторов. Если бы речь шла просто о том, что нужно или не нужно ставить скобки на отдельной строке, это была бы не архитектурная проблема. Но раз речь идёт о том, что можно единообразно относиться к похожим явлениям, и это единообразие поможет избавиться от избыточных описаний в стандарте, то это больше похоже на архитектурную проблему.
Я пишу открывающие скобки на той же строке. Что анонимные, что нет.
Исторически так сложилось. Вот как освою скрипты которые за меня оформление править будут, да доведу свой фреймворк до RC1 (точнее сначала доведу), тогда может начну переучиваться.
Так что да, если бы 12 делал бы на той же строке, то мне было бы удобно.
Но нет, я бы не проголосовал за такое изменение.
Пусть лучше гады переучиваются (и я в том числе), чем скакать туда-сюда.
Ведь в любом случае кто-то будет переучиваться. Или я, или тот парень, который уже научился под PSR.
Исторически так сложилось. Вот как освою скрипты которые за меня оформление править будут, да доведу свой фреймворк до RC1 (точнее сначала доведу), тогда может начну переучиваться.
Так что да, если бы 12 делал бы на той же строке, то мне было бы удобно.
Но нет, я бы не проголосовал за такое изменение.
Пусть лучше гады переучиваются (и я в том числе), чем скакать туда-сюда.
Ведь в любом случае кто-то будет переучиваться. Или я, или тот парень, который уже научился под PSR.
Вы, кстати, упустили ещё одну деталь. В первом варианте фигурная скобка иногда пишется на той же самой строке, что и закрывающая круглая для методов/функций (это есть и в 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.
Так что, случаев больше получается, чем два. А ведь можно было бы всё упростить, если, хотя бы для методов/функций, открывающая фигурная скобка писалась всегда на той же самой строке. Кучу «лишнего кода» ведь можно было бы тогда выкинуть из текста. :)
Это описание стандарта. Важно чтобы при его прочтении не возникло недопонимания, поэтому текст бы никуда не делся, а просто заменили бы фразы "на следующей строке" \ "на этой же строке" на противоположные и все :)
Вы, похоже, не до конца поняли ситуацию и не видите, что после этого возникнет дублирование инфромации, которое можно будет безболезненно удалить из текста, упрощая его. :)
http://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.
На лицо дублирование, но почему-то никто не объединил эти два пункта ;)
Один пункт — одно утверждение
Sign up to leave a comment.
Логирование в Yii 2.0 и PSR-3