Комментарии 52
function ($foo, $bar) {
if ($foo <= 0) return;
if ($bar <= 2*$foo) return;
}
Как по мне, «парсить» негативные условия с unless намного сложнее.
function ($foo, $bar) {
if ($foo <= 0) {
return;
}
if ($bar <= 2*$foo) {
return;
}
}
Если не запретить их синтаксически, только однострочники, как с функциями стрелочными сделали.
unless/guard ни что иное, как if not.
unless($condition) === if (!$condition)Как по мне, это не синтаксический сахар, а синтаксический мусор.
А вот вариант:
return if ($cond);мне кажется более интересным; визуально удобнее усмотреть там ретурн, чем в класическом варианте.
Как по мне, это не синтаксический сахар, а синтаксический мусор.
Спорно. Например, некоторые стайл-гайды запрещают if(!...) хотя по остальным принципам композиции кода типа "в if сначала должна идти основная ветка, а в else особые случаи" (или наоборот, не суть), должно быть именно! в if
P.S. Я вот не борюсь за единую точку выхода, хотя на C писал 30 лет назад.
ОРМка на вид какая то древняя
но насколько это лучше if (condition) return;?
Зачастую, при беглом просмотре кода читается только первый оператор, а что там дальше можно упустить. Автор же, как я понимаю, предлагает сфокусироваться не на том что там какое-то условие, а на то что там вывод. Идея прикольная, но вот синтаксис подвел…
С атрибутами странная тема. Недоаннотации доступные только из рантайма и только через рефлексию. Как-то очень… Спорно.
Во время компиляции например.
Собственно "недо" они потому, что не предусмотрен механизм их произвольного процессинга. Вот эта пляска с рефлексией "по месту" ну никак на таковой не тянет
И не очень понятно, что вы имеете в виду под произвольным процессингом. Не вижу каких-то особых проблем даже для динамической генерации кода произвольного класса на основе «меченного» атрибутами, при условии использования автолоадера. С жёсткими динамическими require динамически наверное не получится без каких-то расширений.
Да, какие-то ограничения у аттрибутов есть, без расширений и/или кодогенерации рантайм декораторы, например, сделать не получится. Но большинство кейсов, если не все, где использовались и используются phpdoc аннотации они вроде как покрывают. Лично я большего и не ожидал.
что вы имеете в виду под произвольным процессингом
Что-то вроде
register_attribute_handler($callable)интерпретируемый язык. Все эти компиляции в опкоды
Опять же, никто не мешал добавить в АПИ zend_extension дополнительный обработчик, что позволило бы сделать атрибуты гораздо более вкусными
Но большинство кейсов, если не все, где использовались и используются phpdoc аннотации они вроде как покрывают.
Ну а я ожидал всё же чего-то поближе к аннотациям, а не те-же доки, вид сбоку
Спасибо, хоть понятно стало, что ощущение бесполезности сей грандиозной штуки было верным. Думал, что понял неправильно.
А что не так с чтением средствами рефлексии? Даже если глянуть на то, как оно в c# работает, то всё что связанно с атрибутами находится в нэймспейсе "System.Reflection" — в пхп же появятся пользовательские библиотеки/psr-стандарты и сделают те же DeveloperAttribute/Attribute.GetCustomAttributes, которые скроют данную рутину под капот. К тому же, как мне кажется, произвольному процессингу место в исключительно юзерленде, а не в php core — всем и сразу не угодишь, и это наглядно видно, если глянуть как эволюционировали rfc, и краем глаза проглядеть связанные трэды на externals связанные с аннотациями/аттрибутами.
С рефлексией в пользовательском коде "не так" примерно всё. Начиная от нарушения инкапсуляции и заканчивая скоростью работы. И если раньше рефлексия в подавляющем числе случаев была уделом фреймворков (не от хорошей жизни), то теперь она локомотивом ворвётся в хелло-ворды разной степени сложности.
как мне кажется, произвольному процессингу место в исключительно юзерленде, а не в php core
Ну а мне кажется иначе.
И самое обидное, что даже путей для отступления не подготовили. С текущей реализацией, даже если очень захотеть, как либо расширить скоп использования будет очень трудно.
И если раньше рефлексия в подавляющем числе случаев была уделом фреймворков (не от хорошей жизни), то теперь она локомотивом ворвётся в хелло-ворды разной степени сложности.
Откуда такие выводы? Несколько популярных библиотек для парсинга аннотаций есть давно. Кто хочет юзает, кто не хочет — нет. Скорее всего их авторы сейчас в поте лица трудятся над прозрачной совместимостью с атрибутами. Что изменится для рядового прикладного разработчика?
А каким образом чтение метаданных/аспектов/декораторов, созданных в большинстве кейсов для чтения из внешней среды, нарушает инкапсуляцию? Или вы собираетесь читать рефлексию только в рамках тех классов где она описана? Тогда получите даже не то что тесную, а скорее неловкую связанность.
По поводу скорости исполнения и рефлексии — никогда тут не понимал — что и с чем вы сравниваете? Исполнение скрипта с рефлексией и без? Ну очевидно, что первое будет быстрее, второе медленнее. Помимо, на гитхабе много gist-заметок, в которых будет видно, что с ростом версии интерпретатора бенчмарки по использованию рефлексии менялись.
Стоит отметить, что такой вид аттрибутов, хоть и не серебрянная пуля, но отлично ложится в opcache, даже несмотря на то, что в нём дозволили ограниченно использовать выражения. Если не понравится рефлексия + opcache, то в своём юзерленд хендлере можете хоть по файликам раскладывать, не используя после первого прогрева рефлексию в рантайме. К тому же, можно сейчас смело пойти и накатать пару RFC и про custom handler (хотя не представляю зачем он) и про встроенный в язык AnnotationReader, ну или хотя бы сделать вброс в externals — до выпуска восьмёрки времени ещё полно.
Для начала ВЫ определитесь, мы про недостатки рефлексии или про метаданые/аспекты/декораторы. Второе можно реализовать множеством способов, а не только рефлексией.
Недостатки я описал чуть выше в диалоге с VolCh (но это моё имхо)
По поводу скорости исполнения и рефлексии — никогда тут не понимал
Ну так вы поинтересуйтесь — оно полезно. Хоть я и указал это, как самое последнее из недостатков, но догадались докопаться.
PS В первый раз я сдержался, но вы настолько активно продвигаете… Мой RFC включен в ядро PHP. Я знаю, что и как там устроено.
PHP Russia Online — Записи стримов: оригинальный на английском, и с переводом на русский.
Роман, а так точно можно было? Мне в письме было написано, чтобы я не делился ссылками на эти записи.
За wp в ядре PHP отдельно спасибо!:))
Роман, а так точно можно было? Мне в письме было написано, чтобы я не делился ссылками на эти записи.
Думаю это предупреждение осталось от офлайн-конфы, где оно имеет смысл. А здесь — мероприятие бесплатное, ссылки и так всем известны, нет смысла в их сокрытии.
Не знаю, в чем конкретно смысл, но после именно онлайн-конференции я получил вот такое письмо:
https://photos.app.goo.gl/M1HCwP2uskVjqVam6
PHP-Дайджест № 180 (4 – 18 мая 2020)