[Перевод] Революция PHP7: Типы возвращаемых значений и удаление артефактов

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

PHP 5.7 vs. PHP7

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

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



Обратите внимание, что пока голосование неоднозначно, это говорит о том, что идея окончательно не похоронена. Участники высказываются против 5.7 из-за отсутствия значительных изменений, но с учетом новых голосов на других RFC, они вполне могут изменеть свое решение. Давайте посмотрим что произойдет.

Типы возвращаемого значения (Return Types)

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

function foo(): array {
    return [];
}

Улучшение? Однозначно!!! Но идеальное ли? К сожалению, нет:

• возвращаемыми могут быть лишь те типы, которые есть на данный момент…
  
  не будет возможности вернуть скалярные значения, такие как string, int, bool и др. Это означает, что ваши методы и функции, которые возвращают подобные значения по-прежнему останутся в исходном состоянии.
  
  Вы можете это исправить это путем возврата экземпляров обертки для подобных значений, но это будет ненужным извращением в большинстве случаев. (прим. пер. — самое время обратить внимание на одно из предыдущих начинаний — преобразование примитивов в нормальные объекты)


• нельзя будет определить возврат нескольких типов. Если ваша функция возвращает либо массив либо объект Iterator, то нет никакого способа указать это, например, array|Iterator как мы делаем в doc-блоках.

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

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

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

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

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

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

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

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

Понятно, сломанная совместимость всегда огорчит некоторых людей, даже если в рамках основных версий все останется нормальным, нарушать совместимость необходимо для целей прогресса. Представьте себе вой, который поднимется, когда подобные люди узнаю об этом. Блин, если бы в прошлом году не был бы обновлнен mysqli заместо mysql, то либо WordPress не смог бы корректно работать на PHP7, либо PHP7 был бы дырявым и безнадежно устаревшим по той единственной причине, что core-разработчики пожалели пользователей WP и решили оставить их счастливыми.

Мой совет тем, кто опасается PHP7 — стоп. Если вы не хотите обновляться, то и не делайте этого. Если вы сидели на 5.3 или 5.2 так долго (привет, любители CodeIgniter), то посидите на 5.6 еще десяток лет, не мешайте PHP быть современным. Оставьте прогресс для тех, кто готов принять его.

Что думаете вы по этому поводу? Вся эта затея с удалением артефактов бред или действительно нужный шаг?

В сторону: изменения Extension API

В качестве интересной заметки на полях, есть некоторые изменения в PHP7, которые могут стать причиной небольшой задержки с портированием расширений на версию 7. API для создания расширений попало под рефакторинг (чистку) и все может поменяться, тем не менее этот провакационный твит от Sara Golemon собрал немного внимания.

Damn. There are some serious surprises in the PHP7 Extension API changes. Not for nothin’, but it’s a good time to switch to HHVM.

— SaraMG (@SaraMG) January 3, 2015

Она в основном говорит о том, что изменения в создании расширений при переходе от 5.6 до 7 будет настолько большими, что проще узнать как делать расширения под HHVM. А затем она продолжает развивать тему серией статей на тему как создать HHVM extension.

Вы разрабатываете расширения? Изучали ли вы изменения и как вы относитесь к всему этому, не слишком ли рано сейчас говорить о будущем эффекте?

Edit: Мое внимание обратили на то, что Сара уже после всего этого начала документировать новое API расширений, совместимое и с HHVM и с PHP7. Похоже, можно делать расширения, совместимые с обоими рантаймами!

Вывод

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

Что вы думаете об этих RFC? Как вы относитесь PHP7 в целом? Движется ли он в правильном направлении? Дайте нам знать — мы хотим услышать ваши мысли!

Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.