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

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

Есть большое фислософское противостояние. Тех кто за ранний выход и тех, кто за единую точку выхода.

За единую точку выхода борятся люди, которые начинали карьеру с Си или раньше. И функциональщики. 30 лет назад действительно были слабые инструменты для поддрежания кода и единая точка выхода имела смысл. У функциональщиков есть крутые инструменты для поддержания читабельности кода, сохраняя единственную точку выхода.

Но лично я за ранний выхода. Если предствавить код логически (как диаграммы ЮМЛ) получается дерево. Где в вершине — вход в функцию, а листья — выход. И если дерево зазбухает в толщину (в стороны) — его сложно читать и понимать за раз. В идеале логика должна быть прямолинейной, с одно-двух строчными отпочкованиями. Которые в большинстве случаев можно даже забыть и не держать в голове.

Поэтому guard и return if — интересны. Но, к сожалению интересны как начало дискусии. Сами по себе они выглядят надуманными.

Возможно лучше было бы ввести новый оператор unless (condition) return/throw/break/continue.
Работает как обратный if. Else запрещен, блок кода запрещен. Должен содержать одно из четырех return/throw/break/continue. Такое предложение существенно улучшит читабельность и будет учить писать код лучше. С другой стороны — оно не дает приемуществ по сравнению со старым кодом.

Тогда я попробую добавить фичу, которой раьнше в языка не было — unless можно цеплять друг к другу:
function ($foo, $bar) {
  unless ($foo > 0)
  unless ($bar > 2*$foo)
    return;
}


Такая фича сокращает код и позволяет быстро выделить дефолтное значиние. И по-сути описать gurad блок
А чем это лучше вот такого варианта?
function ($foo, $bar) {
  if ($foo <= 0) return;
  if ($bar <= 2*$foo) return;
}


Как по мне, «парсить» негативные условия с unless намного сложнее.
1) мы парсим «положительные» условия для основного блока программы
Читать (в уме) надо «для выполнения кода нужно ...». С точки зрения английского guard подходит гораздо лучше. Но в программировании оно занято другим смыслом.

2) Если там не нулл, а дефолтное значение — то его надо менять только в одном месте, а не найти все ранние точки выхода.

3) твой код не пройдет стандартный парсер кодстайла, если он без тюнинга.

4) используя новое слово — его глазами легче понять (и найти) как отдельный кусок фунции (предусловия) а не часть основной логики
> Читать (в уме) надо «для выполнения кода нужно ...».

Надо кому? Я очень люблю early return, сам пользуюсь и хорошо читаю. Увидев новое слово я тупо будут тормозить. Как минимум первый раз (надо погуглить штаэта), ну и потом вспоминая что оно значит.
Тем кто хотят сахара для раннего ретурна.

Сделать пых более читабельным без нового синтаксиса невозможно — мешают борцы за обратную совместимость. Истори со «switch» показательная.
> Сделать пых более читабельным без нового синтаксиса невозможно

Я не понимаю зачем return нужно делать более читаемым чем return. По мне все попытки будут наоборот запутывать.
Блоки разрешены, else разрешены.
Ну в большинстве код стайлов if не принято писать без {}, а с ним уже совсем не так коротко получается
function ($foo, $bar) {
    if ($foo <= 0)  {
        return;
    }
    if ($bar <= 2*$foo) {
        return;
    }
}
Разговор уже начался с добавления фич в язык — guard & return if
следуя этим код-стайлам в анлес также нужно использовать скобки.

Если не запретить их синтаксически, только однострочники, как с функциями стрелочными сделали.

можно, но зачем?
image
Повторю то, что уже тут было написано:
unless/guard ни что иное, как if not.
unless($condition) === if (!$condition)

Как по мне, это не синтаксический сахар, а синтаксический мусор.

А вот вариант:
return if ($cond);

мне кажется более интересным; визуально удобнее усмотреть там ретурн, чем в класическом варианте.
Как по мне, это не синтаксический сахар, а синтаксический мусор.

Спорно. Например, некоторые стайл-гайды запрещают if(!...) хотя по остальным принципам композиции кода типа "в if сначала должна идти основная ветка, а в else особые случаи" (или наоборот, не суть), должно быть именно! в if

Это проблемы гайда и тех, кто им пользуется, а не языка.
С одной стороны — я согласен. в return if важный именно ретурн и его надо подсветить для глаз. С другой стороны — для мозга важнее информация про условие, чем то, что возвращают. Потому что мозг думает «если А то делай Б»
Ну тупите пацаны, зачем ЕЩЕ ОДНИ НЕОЧЕВИДНОСТИ?
Серьездно? Минус в карму?

И после этого люди хотят взвешенных и аргументрированных (вежливых и еще 10 пунктов) комментариев и обсуждений?
И как это цепляние работает? && или ||?

P.S. Я вот не борюсь за единую точку выхода, хотя на C писал 30 лет назад.
Это сахар по сравнению с написанием нескольких ретурнов — поэтому именно «или».

PS я не говорю что _все_ кто писал код 30 дет назад такие. Я говорю что аргументация появилась 30 лет тому и уже однозначно устарела. На самом деле раньше, но 30 лет, максимум 20 лет тому она была хоть частисно актуальна.

ОРМка на вид какая то древняя

Это не ОРМка :) По-моему, библиотека весьма посредственная, и есть куда более качественные альтернативы. Я, признаться, удивлен, что она нахватала столько звезд на гитхабе.
Посоветуйте :) Посмотрел composer.json LessQL — никаких зависимостей кроме PHP, это же замечательно.
Звёзды обычно мало о чем говорят, разве что про определенный уровень хайпа(причем хз когда).
Я согласен с мнением тех, кто призывает смотреть на скачивание и активные issue
но насколько это лучше if (condition) return;?

Зачастую, при беглом просмотре кода читается только первый оператор, а что там дальше можно упустить. Автор же, как я понимаю, предлагает сфокусироваться не на том что там какое-то условие, а на то что там вывод. Идея прикольная, но вот синтаксис подвел…
Зачастую, при беглом просмотре кода читается только первый оператор, а что там дальше можно упустить.

Ну если по кодестайлу код, то следующую строчку все равно читаешь и тут все норм.
if без фигурных скобок считается плохим тоном.

Спасибо за подборку!

С атрибутами странная тема. Недоаннотации доступные только из рантайма и только через рефлексию. Как-то очень… Спорно.

такая же мысль, вообще не понял зачем они нужны, какой от них смысл, курил стичера вдумчиво, но ничего кроме головной боли не накурил.
Я так понимаю, что, например, PHPUnit и Doctrine в ближайшее время на них перейдёт, Symfony и Laravel позже
Почему «недо»? И в каком ещё «тайме» в PHP они могут быть доступны? )

Во время компиляции например.
Собственно "недо" они потому, что не предусмотрен механизм их произвольного процессинга. Вот эта пляска с рефлексией "по месту" ну никак на таковой не тянет

PHP — интерпретируемый язык. Все эти компиляции в опкоды и JIT — лишь оптимизации под капотом.

И не очень понятно, что вы имеете в виду под произвольным процессингом. Не вижу каких-то особых проблем даже для динамической генерации кода произвольного класса на основе «меченного» атрибутами, при условии использования автолоадера. С жёсткими динамическими require динамически наверное не получится без каких-то расширений.

Да, какие-то ограничения у аттрибутов есть, без расширений и/или кодогенерации рантайм декораторы, например, сделать не получится. Но большинство кейсов, если не все, где использовались и используются phpdoc аннотации они вроде как покрывают. Лично я большего и не ожидал.
что вы имеете в виду под произвольным процессингом

Что-то вроде


register_attribute_handler($callable)

интерпретируемый язык. Все эти компиляции в опкоды

Опять же, никто не мешал добавить в АПИ zend_extension дополнительный обработчик, что позволило бы сделать атрибуты гораздо более вкусными


Но большинство кейсов, если не все, где использовались и используются phpdoc аннотации они вроде как покрывают.

Ну а я ожидал всё же чего-то поближе к аннотациям, а не те-же доки, вид сбоку

>Да, какие-то ограничения у аттрибутов есть, без расширений и/или кодогенерации рантайм декораторы, например, сделать не получится. Но большинство кейсов, если не все, где использовались и используются phpdoc аннотации они вроде как покрывают.<
Спасибо, хоть понятно стало, что ощущение бесполезности сей грандиозной штуки было верным. Думал, что понял неправильно.
Как по мне, главная полезность — стандартизация того, что я уже чуть ли не 10 лет использую. Большего чем получения мета-информации, меток по сути, я и не ждал.

А что не так с чтением средствами рефлексии? Даже если глянуть на то, как оно в c# работает, то всё что связанно с атрибутами находится в нэймспейсе "System.Reflection" — в пхп же появятся пользовательские библиотеки/psr-стандарты и сделают те же DeveloperAttribute/Attribute.GetCustomAttributes, которые скроют данную рутину под капот. К тому же, как мне кажется, произвольному процессингу место в исключительно юзерленде, а не в php core — всем и сразу не угодишь, и это наглядно видно, если глянуть как эволюционировали rfc, и краем глаза проглядеть связанные трэды на externals связанные с аннотациями/аттрибутами.

С рефлексией в пользовательском коде "не так" примерно всё. Начиная от нарушения инкапсуляции и заканчивая скоростью работы. И если раньше рефлексия в подавляющем числе случаев была уделом фреймворков (не от хорошей жизни), то теперь она локомотивом ворвётся в хелло-ворды разной степени сложности.


как мне кажется, произвольному процессингу место в исключительно юзерленде, а не в php core

Ну а мне кажется иначе.
И самое обидное, что даже путей для отступления не подготовили. С текущей реализацией, даже если очень захотеть, как либо расширить скоп использования будет очень трудно.

И если раньше рефлексия в подавляющем числе случаев была уделом фреймворков (не от хорошей жизни), то теперь она локомотивом ворвётся в хелло-ворды разной степени сложности.

Откуда такие выводы? Несколько популярных библиотек для парсинга аннотаций есть давно. Кто хочет юзает, кто не хочет — нет. Скорее всего их авторы сейчас в поте лица трудятся над прозрачной совместимостью с атрибутами. Что изменится для рядового прикладного разработчика?

Для простого разработчика изменится порог вхождения в эту тему. Парсить доки самостоятельно — ну такое себе развлечение, подключать либу — нуууу… Это ж надо либу подключать. А тут вот оно, всё под рукой, только и надо, что рефлексию использовать.

По опыту рефлексию не любят использовать, если либы нет. Есть либа для, например, доступа к приватным свойствам — будут использовать в тестах, например, или ORM. Нет — не будут.

Про то и речь, что теперь будет новая крутая фича, которую "по мануалу" надо использовать через рефлексию.

А каким образом чтение метаданных/аспектов/декораторов, созданных в большинстве кейсов для чтения из внешней среды, нарушает инкапсуляцию? Или вы собираетесь читать рефлексию только в рамках тех классов где она описана? Тогда получите даже не то что тесную, а скорее неловкую связанность.


По поводу скорости исполнения и рефлексии — никогда тут не понимал — что и с чем вы сравниваете? Исполнение скрипта с рефлексией и без? Ну очевидно, что первое будет быстрее, второе медленнее. Помимо, на гитхабе много gist-заметок, в которых будет видно, что с ростом версии интерпретатора бенчмарки по использованию рефлексии менялись.


Стоит отметить, что такой вид аттрибутов, хоть и не серебрянная пуля, но отлично ложится в opcache, даже несмотря на то, что в нём дозволили ограниченно использовать выражения. Если не понравится рефлексия + opcache, то в своём юзерленд хендлере можете хоть по файликам раскладывать, не используя после первого прогрева рефлексию в рантайме. К тому же, можно сейчас смело пойти и накатать пару RFC и про custom handler (хотя не представляю зачем он) и про встроенный в язык AnnotationReader, ну или хотя бы сделать вброс в externals — до выпуска восьмёрки времени ещё полно.

Для начала ВЫ определитесь, мы про недостатки рефлексии или про метаданые/аспекты/декораторы. Второе можно реализовать множеством способов, а не только рефлексией.


Недостатки я описал чуть выше в диалоге с VolCh (но это моё имхо)


По поводу скорости исполнения и рефлексии — никогда тут не понимал

Ну так вы поинтересуйтесь — оно полезно. Хоть я и указал это, как самое последнее из недостатков, но догадались докопаться.


PS В первый раз я сдержался, но вы настолько активно продвигаете… Мой RFC включен в ядро PHP. Я знаю, что и как там устроено.

PHP Russia Online — Записи стримов: оригинальный на английском, и с переводом на русский.

Роман, а так точно можно было? Мне в письме было написано, чтобы я не делился ссылками на эти записи.


За wp в ядре PHP отдельно спасибо!:))

Роман, а так точно можно было? Мне в письме было написано, чтобы я не делился ссылками на эти записи.

Думаю это предупреждение осталось от офлайн-конфы, где оно имеет смысл. А здесь — мероприятие бесплатное, ссылки и так всем известны, нет смысла в их сокрытии.

Не знаю, в чем конкретно смысл, но после именно онлайн-конференции я получил вот такое письмо:
https://photos.app.goo.gl/M1HCwP2uskVjqVam6

Уточнил у орг команды — шарить можно. Позже будут еще отредактированные нарезанные и с интересными вопросами из зума.

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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.