Это вторая часть нашей минисерии статей «Чего ждать от PHP7». Читать часть 1

Как вы наверное уже знаете, PHP7 придет в этом году! И сейчас самое время узнать что же нового он нам принесет.

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

Новый экранирующий символ для Unicode

Добавление нового escape-символа \u позволяет нам указывать специфические unicode символы внутри PHP-строк (да-да, те самые emoji и не только).

Синтаксис выглядит так — \u{CODEPOINT}, например, зеленое сердце, , может быть выражено как PHP-строка: "\u{1F49A}".

Это первая часть нашей минисерии статей «Чего ждать от PHP7». Читать часть 2

Как многие из вас, вероятно, знают, было принято RFC о согласовании названия следующей основной версии PHP, которая будет называться PHP7. Вы можете почитать об этом в моем PHP5 timeline.

Независимо от ваших чувств по поводу этой темы, PHP7 — это свершившийся факт, и он придет в этом году! RFC с таймлайном выпуска PHP7.0 прошло практически единогласно (32 к 2), сейчас разработчики подошли к стадии заморозки фич, а первый релиз-кандидат (RC) мы увидим уже в середине июня.

Но что все это значит для нас, обычных разработчиков? Сейчас мы видим огромное нежелание веб-хостеров двигаться в направлении новых версий 5.x. Не приведет ли крупное обновление, ломающее обратную совместимость, к еще более медленному движению?

Ответ: посмотрим. Продолжайте читать и узнаете подробности.

Большая часть проблем с некорректным поведением в нестандартных ситуациях была исправлена. Кроме того, производительность и устранение несоответствия — основные направления для этой версии.

Давайте углубимся в детали.

Есть шутка о типичной карьере разработчика:

1. Не использует фреймворки
2. Обнаруживает фреймворки
3. Пишет свои фреймворки
4. Не использует фреймворки

Пункт 4, конечно же, ссылается на новоприобретенные способности использовать Composer для построения собственных фреймворков, создавая их из различных компонентов третьих сторон.

Все мы знаем, что экосистема PHP не страдает от нехватки различных фреймворков, и поэтому я немного удивился, когда увидел еще один, созданный сравнительно недавно.


Он называется Webiny, и, будучи упакованным до краев усовершенствованиями и изменениями, которые они считают необходимыми, фреймворк имеет некоторые действительно интересные компоненты, на которые стоит взглянуть. В этой вводной статье мы не будем обращать внимание на структуру в целом, но осветим самые основные ее компоненты — StdLib.

Ожидание закончилось! Phalcon 2.0 уже здесь!

После более чем года разработки, мы невероятно рады объявить о выпуске финального релиза Phalcon 2.0.

Все чаще и чаще я вижу, что люди уклоняются от новейших технологий, делая выбор в пользу обратной совместимости. «Мы не можем повышать минимальные требования к PHP до 5.5, потому что у нас 50% пользователей еще на 5.4» говорят они. «Нет никакого способа обновиться до Guzzle 4+, у нас бекенд на версии 3 и переделывать его слишком долго и дорого». И самый лучший аргумент от WordPress: «Мы не может придти к полному ООП, потому что большинство пользователей сидят на shared-хостингах с 5.1 или не знают про MVC».

Нонсенс.

Legacy-код – это большое НЕТ

Возможно, это спорный вывод, но я твердо уверен, нет места для legacy-кода в современных системах. Скажу несколько слов, прежде чем вы начнете точить свои вилы и зажжете факелы. Я имею ввиду, что не должно быть ни малейшего повода поддерживать старый функционал, вы добавляете обновления задним числом к старой версии только потому, что некоторые люди все еще используют ее. Даже если этих людей большинство — не делайте так.

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

PHP 5.7 vs. PHP7

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

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

Repository commonly refers to a storage location, often for safety or preservation.
— Wikipedia

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

Репозиторий как коллекция

Вероятно, наиболее важным отличием репозиториев является то, что они представляют собой коллекции объектов. Они не описывают хранение в базах данных или кэширование или решение любой другой технической проблемы. Репозитории представляют коллекции. Как вы храните эти коллекции — это просто деталь реализации.

Я хочу внести ясность в этот вопрос. Репозиторий — это коллекция. Коллекция, которая содержит сущности и может фильтровать и возвращать результат обратно в зависимости от требований вашего приложения. Где и как он хранит эти объекты является ДЕТАЛЬЮ РЕАЛИЗАЦИИ.

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

Я исследовал различные варианты дя версионирования REST API. Большинство источников, которые я нашел, говорят практически одно и тоже. Для версионирования любого ресурса в интернете вы не должны изменять URL-адрес. Веб не версионный, и изменение URLа говорит клиенту, что есть больше чем 1 ресурс. Но на самом-то деле не существует нескольких ресурсов, это просто разные представления одного и того же. Конечно, бывают случаи, когда необходимо изменить URL, например, когда измененяется функциональность. В данном конкретном случае причиной изменения служит тот факт, что это больше не один и тот же ресурс.

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

Некоторое время назад назад Энтони Феррара выразил мысли по поводу будущего PHP. Соглашусь с большинством его взглядов, но не со всеми. В статье я остановлюсь на одном конкретном аспекте: преобразования примитивных типов данных, таких как строки или массивы, в “псевдо-объекты”, позволяя выполнять в них вызовы методов.

Начнем с нескольких примеров:

$str = "test foo bar";
$str->length();      // == strlen($str)        == 12
$str->indexOf("foo") // == strpos($str, "foo") == 5
$str->split(" ")     // == explode(" ", $str)  == ["test", "foo", "bar"]
$str->slice(4, 3)    // == substr($str, 4, 3)  == "foo"

$array = ["test", "foo", "bar"];
$array->length()       // == count($array)             == 3
$array->join(" ")      // == implode(" ", $array)      == "test foo bar"
$array->slice(1, 2)    // == array_slice($array, 1, 2) == ["foo", "bar"]
$array->flip()         // == array_flip($array)        == ["test" => 0, "foo" => 1, "bar" => 2]

Здесь $str — это обычная строка и $array является простым массивом — они не объекты. Мы просто даем им немного объектного поведения, позволяя вызывать в них методы.

Обратите внимание, такое поведение совсем не за горами. Это уже не сон, кое-что уже существует прямо сейчас. PHP расширение scalar objects позволяет определить методы для примитивных типов.

Статья является переводом 25 PHP Developers to Follow Online.

Создание PHP фреймворков — это тяжелое занятие, но следить за их развитием и деятельностью коммиттеров в Твиттере — очень просто. Если вы захотите увидеть в какую сторону движется PHP-сообщество, что сейчас является трендом и какие инструменты применяются в передовых проектах, просто посмотрите, подпишитесь на этих людей.