Как стать автором
Обновить

Комментарии 58

> Brent Roоse привел несколько убедительных аргументов в пользу #[ ]:

> Такой же синтаксис в Rust.

Хах, Rust уже становится законодателем мод? )

Еще два возможно интересных лайва в этом месяце:

1. В эту пятницу (26.06) на ютубе будет лайв-запись интервью с самим Романом о PHP-дайджесте и не только.

2. В следующую среду (1.07) на ютубе будет интерактивная лайв-запись подкаста SDCast
о код-ревью с Александром Макаровым, Сергеем Жуком и не только: сслыка на эфир появится в ближайшие дни на этом канале.
UPD. Появилась прямая ссылка на предстоящий лайв о код-ревью.
Тема переименования потенциально неполиткорректных терминов не обошла стороной и PHP-мир.

Совсем с дубу рухнули… Делать им нечего. На месте SamDark я бы послал их лесом, а не поддавался на провокации. =\

Мир сходит с ума, ладно списки, больше негодования вызывает переименование master в main, такое ощущение что у слова мастер только один перевод существует. А потом мы main переименуем во что-то более корректное, т.к. превосходство одного человека над другим это оскорбительно и все должны быть равны.

Не, ну оправдания ради, те изменения что в PR Yii (на которые я ссылался в комменте выше) действительно улучшают в некоторых местах читаемость.

Exclude/include часто понятнее, чем blacklist/whitelist.

Поэтому и применили. Там была ещё попытка master/slave переименовать и primary/replica, но в итоге откатили. Технически получилось очень плохо. Оно того не стоит.

Но ведь семантика терминов «whitelist» и «include[list]» совершенно разная!

Во-первых, как «blacklist», так и «whitelist» — списки исключений. Например, в каком-нибудь условном адблоке адреса из белого списка являются исключениями из общих правил блокировки, не должны проверяться регулярками и пролетать насквозь. И точно также адреса из чёрного списка являются исключениями из общих правил — они тоже не должны проверяться, а сразу блокироваться. Уже здесь назревает путаница, потому что в новой терминологии теперь есть свои «исключения» — «exclude»! А «include» рядом ещё и создаёт впечатление, что для того, чтобы с объектом было проведено какое-то действие, он должен быть «включён» в список «includelist», а это не так.

Во-вторых, разные проекты заменяют «неполиткорректные» старые термины разными новыми. Где-то это «blocklist», где-то «stoplist», где-то «excludelist», где-то просто «exclude». Такая фрагментация только добавит проблем.

В-третьих, новые термины ещё и весьма неоднозначные — например в xdebug теперь есть XDEBUG_PATH_INCLUDE. Это что — путь, по которому что-то лежит? Как CPLUS_INCLUDE_PATH? Нет. А читается именно так.

Эту дичь следует остановить немедленно. Я уверен, что людей, которые не одобряют такие изменения, достаточно, однако всеобщее внедрение в проектах «кодексов поведения» приводит к тому, что они даже боятся высказаться против, потому что «Расист! Расист!». Наблюдаем ru.wikipedia.org/wiki/Спираль_молчания во всей красе.

Высказаться не против, но куда высказываться? Из всех людей которых я знаю никто не одобрил такие переименования.

Не знаю как там в разных проектах, но в Yii стало понятней после переименования, чем было до.

У меня задача — сделать максимально хорошо фреймворку как долгосрочному проекту. Если переименование технически не делает плохо и весомая часть сообщества становится от этого счастливее, не вижу причин не переименовать. Если при этом читается лучше, то появляется ещё и личная мотивация это сделать.

весомая часть сообщества становится от этого счастливее
13 дизлайков, и 1 лайк под тем МРом, если посмотреть, то почти все МРы на переименования, задизлайканы, что показываем что не всем это нравится.

Конечно не всем. Это не нравится тем, у кого культурно-исторический бэкграунд не такой и они откровенно не понимают, как на такое можно обижаться и вообще зачем оно надо. Все дизлайки там как раз от наших ребят и да, понятно почему. Потому что проблемы у нас этой нет и никогда не было. Но это не значит что её нет у других. Если посмотреть на фидбек в том же твиттере, становится понятно, что всё-таки многим это, как ни странно, важно.

Помимо собственно культуры (что очень важно!) есть еще нюанс, что для нас термин на неродном языке. Ну мастер, ну слейв — делов-то. А вот было бы по-русски (какой-нибудь там 1C) — хозяин / раб. Уже немного корежит, правда?

Кого будет корежить от этого после событий 17-го года? Нет больше ни хозяев, ни рабов ( в правовом поле) и очень давно.
А вот было бы по-русски (какой-нибудь там 1C) — хозяин / раб
Пример подобран не совсем корректно, поскольку «хозяин» в русском языке в основном воспринимается довольно однозначно, а «master» несёт в себе несколько совершенно разных значений, если я не ошибаюсь.

P.S.: К тому же, запрет слова «хозяин» может оскорбить чувства любителей БДСМ.
Этот фидбек показывает только общую безграмотность.

en.wikipedia.org/wiki/Blacklisting#Origins_of_the_term

Сам термин несколько старше расовой проблемы и дискриминации применительно к афроамериканцам, что и явилось основой движения против термина.
Иногда задаю вопрос, этим борцам за социальную справедливость, читали ли они Бредбери, а именно «451º по Фаренгейту». По моей скромной статистике только 1 лайк и 0 ответов, вообще каких либо.

Антиутопии читать не всем приятно, как и читать в общем. Пожалуй, Harrison Bergeron подходит к экстремальным проявлениям чуть лучше, чем Бредбери.

Спасибо, прочту!

Предлагаю выпилить из php оператор подавления ошибок, тогда синтаксису @Attr ничего мешать не будет.
Боюсь тогда придется выпилить из PHP все ворнинги и заменить их на эксепшены.
К примеру такой код:
$а = file_get_contents('https://domain.com');

Выкинет ворнинг если удаленный ресурс недоступен. И это нормально, что удаленный ресурс может быть недоступен. Только еслиб эта функция бросала эксепшен, то я просто обернул бы ее в try… catch и обработал бы ошибку как надо. В текущем же варианте, чтоб не засорять лог ошибок, приходится добавлять @ перед этой функцией и лишь затем проверять, а не произошла ли ошибка.

Конечно можно решить эту проблему с помощью set_error_handler, но данный механизм крайне не гибкий и неудобный в использовании, ведь в место того, чтоб ловить ворнинг в конкретном одном месте оно будет ловить ворнинги отовсюду в коде, хотя как раз там нужно чтоб они сыпались в лог.
Заменить все нотисы и ворнинги на эксепшны тоже давно пора. Я вообще ждал этого в 7.0 и был дико разочарован, когда оказалось, что на эксепнны заменили только фаталы.

В любом случае все фреймворки и так ловят ошибки с помощью set_error_handler и бросают там соответствующие эксепшны. Да и в велосипедных решениях часто практикуется именно такой подход.

А вот сколько лет назад я последний раз видел код с собакой — я наверное и не упомню уже.
Конечно можно решить эту проблему с помощью set_error_handler, но данный механизм крайне не гибкий и неудобный в использовании, ведь в место того, чтоб ловить ворнинг в конкретном одном месте оно будет ловить ворнинги отовсюду в коде, хотя как раз там нужно чтоб они сыпались в лог.
Делают и в «конкретном одном месте»:
set_error_handler(self::$emptyErrorHandler);

$value = include $fileName;

restore_error_handler();
Если ворнинги засоряют лог ошибок, то всегда можно выставить нужный log level. Ваш КО :) Вообще забавно как с одной стороны синтаксис языка делают все строже чтобы программист не дай бог ничего не смог нашкодить, а с другой дают ему такой инструмент как подавление ошибок с помощью @. Давно пора использовать @ в качестве атрибутов.
Поддерживаю. Причем выпилить не столько оператор подавления, сколько сами ошибки в принципе. Наличие разных сущностей для одного и того же — Exception и Error (+ не забываем про return false местами, можно вообще запретить return bool — без него нормально было бы) — существенно усложняет жизнь.

upd: пока читал статью и писал коммент — выше уже сказали про замену ошибок на эксепешены…
T_PAAMAYIM_NEKUDOTAYIM — этот факт даже был обозначен как проблема № 1 в списке грустей PHP.

Если кому интересно, то PAAMAYIM NEKUDOTAYIM это на иврите "פעמיים נקודתיים" означает дважды двоеточее.
возможно этот список составил скрытый антисемит!

От предложенного синтаксиса аннотаций у меня кровоточат глаза. Вариант с #[] реально лучше выглядит.

Мне изначально тоже так показалось, но потом я прочитал RFC. Да и в целом: закладывать логику в комментарии — довольно спорная идея. Вариант с собачками весьма неплох.

В целом я больше привык к аннотациям в стиле Java или C#, и там и там они выглядят неплохо. Вариант с комментом можно сделать отдельным синтаксисом, который с первого взгляда выглядит как комментарий, но для языка является синтаксической конструкцией, при этом сохраняется хоть какая-то обратная совместимость со старым версиями php как бонус.

при этом сохраняется хоть какая-то обратная совместимость со старым версиями php
На мой взгляд это ещё один способ усложнить жизнь.
Ностальгия
<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

Особенно вот это круто
$object = new #[ExampleAttribute] class () {};
$f1 = #[ExampleAttribute] function () {};
$f2 = #[ExampleAttribute] fn() => 1;
В Symfony 6 для конфигов будут использоваться PHP-файлы вместо YAML или XML.

Никогда не понимал зачем вообще эти форматы используются в PHP фреймворке
Для более гибкой работы при развёртывании, всякие jenkins и прочие CI/CD могут без проблем редактировать YAML или XML.
НЛО прилетело и опубликовало эту надпись здесь
Возможность использовать php для конфигов была и раньше. YAML просто более удобный.
В файлах конфигурации на PHP можно выполнять код, и эта «фича» далеко не всегда желательна.
1. Чтобы не было соблазна писать туда любой код и вообще делать конфиги слишком динамичными.
2. Связка PHPStorm + Symfony plugin = автокомплит прямо в yaml-конфиге. Будет ли он реализован и таким же удобным как в yaml? Сейчас я не вижу подсказок для php-конфигов.
3. Можно использовать конфиги на php (в 4 и 5 версиях) и все доки это учитывают.

Ссылка из поста, если я правильно понял, на PR о внутренних и библиотечных конфигах. У меня глаза кровоточили когда надо было заглянуть в конфиг symfony или бандла, а там внезапно xml.
А с дебагом, имхо, самый частый подход — dump & die в легких случаях и дебаггер, когда прям вообще дичь непонятная происходит)

Если какой-то framework — там в этом dump может быть столько всего что замучаешься листать :)


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

Тут напрямую от ситуации зависит, что то мелкое — dump, непонятно что происходит — xdebug.

Согласен, хотя простота запуска отладчика меня совсем избаловала… :)

В дебаггере мне не нравится один момент — когда в шторме начинаешь переходить по строкам дальше то он начинает переходить в автозагрузчик, в методы композера, в которых подключаются файлы, и тут можно клацать кол часа что бы пройти пару строчек кода

Это легко решается в PhpStorm. В настройках Preferences | Languages & Frameworks | PHP | Debug | Step Filters нужно добавить пути, которые вас не интересуют и отладчик автоматически их будет пропускать.



Дока: https://www.jetbrains.com/help/phpstorm/step-filters.html#ff36ae77

есть симфоневский вардампер и блакфайр (странно, как еще не перименовали). иксдебаг чересчур тяжелый.

Совсем уже поехали с переименованиями. Как будто это как-то повлияет на реальность.
Спасибо за подборку!
$country = $session?->user?->getAddress()?->country;


Зачем? Как в цепочке обработать null?
Это тоже самое что и подавление ошибок @ — зло

не тоже.
например, в js/typescript используется. очень удобно.

Очень удобно что?

for($i = 0; $i < 100; ++$i) {
...
  $country = $session?->user?->getAddress()?->country;
  $district = $session?->user?->getAddress()?->district;
  $street = $session?->user?->getAddress()?->street;
...
  $user?->setName($cache?->getUser(1)?->name); // nice
...
}


Зависит от задачи. Если ты парсишь сторонние ресурсы и предполагаешь что каких то полей может не быть, но сохранить все равно хочешь, пусть и с пустыми полями то такой вариант намного лучше и читабельнее чем плодить 100500 if(!empty())

Если надо обработать null особым образом, а не просто null вернуть, то не используйте.

Также сделали правила для PHP_CodeSniffer для поиска «плохих» слов.


Не «сделали», а открыли issue и начали обсуждение. Кроме обсуждения, там ничего нет.

Поправил текст, спасибо.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории