В связи с приближением запланированной даты выпуска PHP 7, внутренняя группа усердно работает над тем, чтобы как можно больше исправить наш любимый язык, удалив артефакты и добавив некоторые давно нужные функции. Есть много RFC, которые мы могли бы изучить и обсудить, но в этом посте я бы хотел остановиться на трех, которые привлекли мое внимание.
PHP 5.7 против PHP 7
Как я упоминал в последнем выпуске бюллетеня , 5.7 было отвергнуто в пользу перехода непосредственно на PHP 7. Это означает, что новой версии между 5.6 и 7 не будет — даже если новая версия должна была служить лишь сигнальной лампой для тех, кто все еще застрял на устаревшем коде. Изначально в 5.7 не должно было быть новых функций, но он должен был выбрасывать уведомления и предупреждения об устаревании кода, который должен измениться в v7.
Он также предупреждает о некоторых ключевых словах, которые должны быть зарезервированы в PHP 7, чтобы люди могли ускорить работу своего кода с помощью своего рода «автоматической» проверки совместимости в форме всей версии PHP. Однако, как я утверждаю в новостной рассылке, дело в том, что большинство людей, обладающих достаточной технологией и способностью следовать PHP на своем пути обновления, следя за самой последней версией, обычно не являются теми людьми, которые на самом деле используют код, который может сломаться. в PHP 7.
Обратите внимание, что, хотя голосование окончено , это не мешает его возрождению в более поздний момент времени. Избиратели «нет» в первом туре, похоже, выступили против 5,7 из-за отсутствия значительных изменений, но с недавними изменениями и новыми голосами по другим RFC, которые вполне могут быть пересмотрены. Давай посмотрим что происходит.
Типы возврата
Подавляющее большинство проголосовало «да», PHP, наконец, получает типы возврата. Результаты голосования еще свежи, но однозначны. Начиная с PHP 7, мы наконец-то сможем указать правильные типы возвращаемых функций в виде:
function foo(): array {
return [];
}Улучшение? Определенно! Но идеально? К сожалению нет:
- возвращаемые типы могут быть только теми, что мы имеем для типов прямо сейчас , то есть не иметь скалярных значений, никаких возвращаемых типов, таких как string , int , bool и т. д. Это означает, что ваши методы и функции, которые возвращают такие значения, все еще будут без знака. Вы можете исправить это, возвращая экземпляры оболочек для таких значений, но в большинстве случаев это излишне.
- нет нескольких типов возврата. Если ваша функция возвращает либо массив, либо объект Iterator, нет способа указать это через, например,
array|Iterator
Некоторые люди также жаловались на то, что объявление типа находится после закрывающей круглой скобки списка аргументов, а не перед именем функции, но для меня это придирчивость. Популярные языки, такие как современный C ++, используют синтаксис «после» и, как и RFC-состояния, это сохраняет возможность поиска «функции foo» без каких-либо необходимых модификаций регулярных выражений. Более того, это соответствует тому, что использует HHVM, так что это дополнительный непреднамеренный бонус совместимости.
Другие жаловались на «строгость» PHP, но, как утверждает один из комментаторов, вы действительно обнаружите ценность этого, когда начинаете кодирование с использованием интерфейсов или наследование кода других людей. Кроме того, пока он не является обязательным и его существование никоим образом не влияет на общую производительность или стабильность PHP, в этом нет никакого вреда. Жаловаться на это, для меня, все равно, что жаловаться на добавление ООП в PHP, когда процедурные спагетти работали так хорошо в большинстве случаев тогда. Языки развиваются, и это шаг в правильном направлении.
Как вы думаете?
Удаление артефактов
В следующей версии предлагается удалить конструкторы в стиле PHP4 (за которые еще не проголосовали). Вы можете прочитать, что это значит в RFC, это просто и было бы бесполезно повторять это здесь, но что действительно очень интересно, так это душевная мука, которую, похоже, вызывает такой шаг у некоторых людей. Например, это . «Пожалуйста, не ломайте наш язык» , — умоляет Тони, который, похоже, намерен использовать его неработающие функции.
Пост хорошо написан, несмотря на очевидный гнев, но меня удивляет — если вы так долго поддерживали такую кодовую базу, есть ли необходимость в обновлении до PHP 7? И если есть необходимость в обновлении до PHP 7, не проще ли просто выследить нарушающие классы и исправить их конструкторы? Конечно, это то, что вы можете делегировать младшим, учитывая достаточное количество модульных тестов в вашей кодовой базе, чтобы убедиться, что все идет хорошо? И если у вас нет модульных тестов, если ваше приложение беспорядок, вы действительно надеетесь получить какую-либо выгоду от перехода на PHP 7? Не лучше ли вам сначала модернизировать приложение ?
Предложение «Это означает, что код, который я написал 10 лет назад, должен работать и сегодня, и должен работать 10 лет». Для меня это безумие — вы определенно и абсолютно не должны ожидать этого от ЛЮБОГО языка в основных версиях. Чтобы провести параллель с реальным миром, вы не должны ожидать, что вам позволят иметь рабов сегодня только потому, что закон давным-давно сказал, что вы можете. Да, разрыв до нашей эры наступил после кровавой революции, но когда большинство рабовладельцев покаялись или умерли, наступил мир.
Конечно, Тони прав в том, что потребуются усилия для удаления этой функции, в то время как для ее удаления не потребуется ничего. Но в долгосрочной перспективе потребуется больше коллективных усилий для устранения проблем, которые иногда вызывают эти конструкторы, чем для удаления это прямо сейчас.
Понятно, что перерывы в BC всегда расстраивают некоторых людей, даже если с основными версиями все в порядке, если перерывы в BC идут ради прогресса. Но представьте себе пыл, когда такие люди узнают об этом . Черт возьми, представьте, что произошло бы, если бы WordPress не вступил в 2001 году в прошлом году и не обновил mysqlimysql
Мой совет тем, кто боится PHP 7 — остановись. Если вы не хотите обновляться, не надо. Если вы могли бы быть на 5.3 или 5.2 так долго (глядя на вас, CodeIgniter), вы можете быть на 5.6 в течение еще одного десятилетия — но позвольте нам иметь современный PHP. Оставьте прогресс тем, кто готов его принять.
Что скажете вы? Является ли это удаление артефактов бессмысленным или необходимым?
В сторону: Расширения API Изменения
В качестве интересного примечания, в PHP 7 есть некоторые изменения, которые могут вызвать задержку при переносе расширения на версию 7. API для создания расширений PHP все еще находится в процессе обновления (читай: очистка), и все подлежит изменение — тем не менее, этот провокационный твит от Сары Големон собрал немало внимания.
Черт. Есть некоторые серьезные сюрпризы в изменениях в PHP7 Extension API. Не для ничего, но самое время перейти на HHVM.
— SaraMG (@SaraMG) 3 января 2015 г.
Она в основном говорит, что изменения в разработке расширений с 5.6 до 7 будут настолько велики, что вы также можете научиться делать расширения HHVM. Затем она приступила к созданию длинной серии на эту тему, подробно объясняя и на примерах, как создать расширение HHVM .
Вы разрабатываете расширения? Вы изучали изменения или чувствуете, что еще слишком рано говорить, будут ли они иметь эффект?
Редактировать: Мне стало известно, что Сара позже начала документировать новый API расширения, совместимый как с HHVM, так и с PHP 7. Кажется, у нас могут быть расширения, совместимые с обеими средами исполнения!
Вывод
Как обычно, нет недостатка в драме на PHP-земле. Как и все основные революции в истории, революция PHP 7 также будет проливать кровь, прежде чем производить что-то потрясающее. До PHP 7 еще далеко, поэтому, даже если вы попали под перекрестный огонь выстрелов из мушкета, у вас будет достаточно времени, чтобы укрыться. Если вы не спали под гусеницами танка , то с обеих сторон мало что можно сделать, чтобы помочь вам.
Что вы думаете об этих RFC? Как вы относитесь к PHP 7 в целом? Он движется в том направлении, в котором вы хотели бы двигаться? Дайте нам знать — мы хотим услышать ваши мысли!