НашСамогон - самогонные аппараты, дубовые бочки, винные и турбо дрожжи, электроника и оборудование для производства алкоголя в домашних условиях.

Революция PHP 7: Возврат типов «return» и удаление артефактов

0

Релиз PHP 7 быстро приближается, а группа разработчиков работает над тем, чтобы как можно быстрее устранить недостатки нашего любимого языка программирования, удаляя устаревшие продукты и добавляя наиболее ожидаемые функции. Есть много RFC, которые стоит изучить и обсудить, но в этой статье мы хотели бы остановиться на трех вещах, которые привлекли наше внимание.

PHP 5.7 vs PHP 7

Вместо 5.7 сразу идет версия PHP 7. Это означает, что не будет никакой промежуточной версии между 5.6 и 7 – даже если бы новая версия служила бы только в качестве сигнала сирены, для тех, кто застрял на устаревшем коде. Первоначально, не предполагалось, что 5.7 не будет иметь новых функций, а предполагалось избавиться от замечаний и осуждений в сторону  устаревших средств языка программирования, которые должны были быть устранены в 7 версии.

Rotlicht leuchtend

Она (сирена) могла бы, также, оповестить некоторых ключевых словах, которые будут представлены в PHP 7, для того, чтобы люди могли писать код быстрее, со своего рода «автоматическим» средством проверки совместимости всей PHP версии. Дело в том, что те люди, которые технологически достаточно подкованы для того, чтобы работать с последовательно выходящими новыми версиями PHP, в большинстве случаев, не будут использовать код, который не будет работать на PHP 7.

А тем временем, что сделано, то сделано и голосование уже окончено. Что Вы думаете на этот счет?

Возврат типов «return»

Вместе с подавляющим большинством проголосовавших «за» PHP, наконец, возвращает типы «return». Результаты голосования все еще свежие, но определенно точные. Начиная с PHP 7, мы, наконец, сможем надлежащим образом указывать типы return на функциях в подобной форме:

Улучшения? Да! Но, без ошибок не обошлось:

  • Типы return могут быть только такими типами, которые мы имеем на сегодняшний день, имеются в виду скалярные значения, никаких типов как последовательность, интервал, логический тип данных и т.д. Это значит, что Ваши методы и функции, которые возвращают подобные значения, будут оставаться неподписанными. Вы можете исправить это возвращая экземпляры обертки этих значений, но это бывает лишним, в большинстве случаев.
  • Нет большого количества return типов. Если Ваша функция возвращает как индексируемый тип, так и объект итератор, то нет никакого способа указать это, например, через array|Iterator ,как мы делаем это в docblocks.

Одни жаловались на то, что обозначение типа было после закрывающей скобки списка аргументом, а не до названия функции, но нам кажется, что это уже придирка к мелочам. Популярные языки, как современный C++ используют «после» синтаксиса, и по положению RFC, это сохраняет возможность поиска для “function foo” без необходимости модификаций regex. К тому же, это соответствует тому, что использует HHVM, так что можно считать, что это непреднамеренный бонус.

Thumbs up vote - Like

Другие жаловались на то, что PHP «сужается», но Вы действительно поймете значение этого тогда, когда начнете писать код против интерфейсов или наследовать код других людей. Кроме того, пока его опциональность и существование в целом ни коим образом, не влияет на общую работу или стабильность PHP, в этом нет ничего плохого. На наш счет, жаловаться на это, то же самое, что жаловаться на то, что  OOP добавляют в PHP. Языки развиваются и это – шаг в правильном направлении.

А что думаете Вы?

Удаление артефактов

Предстоящая версия предлагает удалить конструктор стиля PHP4. Вы можете  прочитать, о том, что это значит в RFC, здесь нет ничего сложного и нет необходимости говорить об этом в нашей статье, но что интересно – такое движение вызывает у некоторых людей ментальное мучение. Например, это: «Пожалуйста, не ломайте наш язык», умоляет Тони, который, кажется, полон решимости относительно использования сломанных функций.

Car breakdown in France

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

Предложение «это значит, что код, который написан 10 лет назад должен работать и сегодня, и должен проработать еще 10 лет»  по нашему мнению является глупостью. Вы не должны ожидать подобного ни от одного современного языка. Чтобы провести параллель с реальным миром, Вы не должны ожидать того, что Вам разрешат иметь рабов, просто потому, что когда-то какой-то закон разрешал подобное. Да, наша эра наступила после кровавой революции, и когда рабовладельцы раскаялись или умерли, наступил мир.

Man fist, vector format

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

Понятно, что революции всегда всех печалят, даже если большинство людей понимает, что это во имя прогресса. Но представьте себе их реакцию, когда они поймут это. И представьте, что было бы, если бы WordPress не вышел в 2001 году и имел бы обновление mysqli вместо mysql. Или ни одна установка WP не будет работать на PHP 7, или PHP 7 будет держать незащищенную и всеми осуждаемую функцию,  на радость пользователям WP.

Наш совет тем, кто боится  PHP 7 – перестать бояться. Если Вы не хотите обновляться, не надо. Если Вас так долго устраивала версия 5.3 или 5.2, то Вы можете еще десять лет пользоваться версией 5.6, но дайте остальным насладиться более современной версией PHP. Дайте принять прогресс тем, что хочет этого.

А как Вы считаете? Является ли удаление артефактов нонсенсом или необходимостью?

Кстати: Расширения API изменяются

В качестве интересной заметки на полях, скажем о некоторых изменениях в  PHP 7, которые могли бы стать причиной задержки расширения для 7 версии. API для строительства расширений PHP все еще является объектом процесса обновления (читай чистки) и все подлежит замене. Тем не менее, провокационный твит от Сары Големон привлек достаточно внимания.

Черт. Грядут некоторые серьезные сюрпризы c изменением PHP7 Еxtension API. Все или ничего. Самое время переключиться на HHVM.

– SaraMG (@SaraMG) 3 января 2015.

На самом деле, она имеет в виду, что изменения в развитии расширения от 5.6 до 7 такие большие, что вы могли бы также научиться работать с расширением HHVM. Далее она подробно и с примерами показала, как создать расширение HHVM.

А Вы развиваете расширения? Изучили ли Вы изменения или Вам кажется, что еще рано говорить о последствиях?

Вывод

Как обычно, на планете PHP нет недостачи в области драмы. Как и сложилось исторически, революция PHP 7 пустит немного крови до того, как явит миру нечто прекрасное. Но есть еще достаточно времени, чтобы найти себе укрытие.

Что Вы думаете об этих RFC? Что Вы можете сказать о PHP 7 в целом? Идет ли он в том направлении, в котором Вы ожидали, что он будет идти? Нам очень интересно узнать Ваше мнение!

Поделиться:

Об Авторе

Переводчик портала WebDesignMagazine.ru. Пишу статьи и делаю переводы для веб-сайта.