Новые возможности PHP 7.3 [Complete guide]

Введение
Пару дней назад,

мой коллега показал мне телевизионную рекламу, которая транслировалась по телевидению несколько лет назад.

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

Британские и немецкие солдаты после нескольких месяцев конфликта вышли из окопов и заключили перемирие с большим количеством смеха и футбольных матчей,

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

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

произошел невероятный технологический прогресс, достаточно вспомнить фильм «Игра в имитацию» Мортена Тилдума.
вот видео

Я считаю, что то же самое верно и для PHP,

улучшения, даже небольшие, в языке, синтаксисе и коде в целом всегда приносят хорошее настроение и надежду на то, что в течение месяцев,

даже годы вперед,

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

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

Некоторые из новых функций запрашивались годами,

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

в этом посте вы узнаете, какие фичи будут реализованы в новом PHP 7.3 и какие оси в рукаве вы сможете похвастать с его релиза.

Следите за серией…
Этот пост является второй частью статьи «PHP 7.3 и его рождественские подарки».

Если вы еще не читали другие части

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

Новые особенности
JSON_THROW_ON_ERROR
Отсутствие адекватного способа обработки ошибок при использовании JSON уже давно является проблемой, и веб-разработчики во всем мире считают это огромным недостатком языка.

RFC для PHP 7.3 принял это обновление 23 голосами против 0, что говорит о том, насколько эта функция была запрошена.

До версии PHP 7.2 нам нужно было использовать обходной путь, чтобы получить ошибку из JSON, и он не был ни надежным, ни опытным в своей работе;

Вот пример:

json_decode("{");
json_last_error() === JSON_ERROR_NONE // the result is false
json_last_error_msg() // The result is "Syntax error"

Да,

мы можем определить, была ли ошибка в JSON,

но это явно не лучший способ сделать это.

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

Давайте посмотрим на практический пример, не так ли?:

use JsonException;
 
try {
    $json = json_encode("{", JSON_THROW_ON_ERROR);
    return base64_encode($json);
} catch (JsonException $e) {
    throw new EncryptException('Could not encrypt the data.', 0, $e);
}

Как видно из предыдущего кода, функция json_encode теперь имеет необязательный параметр JSON_THROW_ON_ERROR, который перехватит ошибку и отобразит ее, используя следующие методы исключения:

$e->getMessage(); // like json_last_error_msg()
$e->getCode(); // like json_last_error()

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

Это одна из самых важных функций обновления, поэтому, если вы хотите узнать больше, посмотрите официальный RFC для JSON_THROW_ON_ERROR.

Is_countable
Счетный элемент в вашем коде может быть переменной с форматом массива или объектом, класс которого реализует интерфейс Countable.

В прошлом году в PHP 7.2 было добавлено предупреждение, которое появляется всякий раз, когда веб-разработчик подсчитывает или пытается зациклить неисчисляемый элемент.

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

if (is_array($santa) || $santa instanceof Countable) {
    // $santa is countable
}

Код проверяет, является ли переменная массивом или экземпляром интерфейса Countable.

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

Команда, разрабатывающая новую версию, учла это и добавила новую функцию, которая очень поможет веб-разработчику.

Функция is_countable принимает переменную в качестве параметра, а затем возвращает логическое значение в зависимости от того, является ли функция счетной или нет.

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

Посмотрим на практике

if (is_countable($santa)) {
    // $santa is countable
}

Этот фрагмент в основном делает то же самое, что и предыдущий, но его гораздо легче запомнить и, что наиболее важно для меня, он более удобочитаем.

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

Дополнительные сведения об is_countable см. в официальном RFC.

array_key_first(), array_key_last()
Согласно версии 5.6 PHP существует более 75 встроенных функций, относящихся к категории массивов.

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

Другой способ — выбрать end() или reset().

Как вы, возможно, знаете, все только что описанные методы изменяют указатель массива, а это то, что (кроме потребления ресурсов) вы просто не хотите делать.

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

Четыре метода были:

array_key_first()
array_key_last()
массив_значение_первый()
массив_значение_последний()
Среди четырех из них только тот набор, который приносит ключи, был принят с 18 голосами против 14.

Они работают как для числовых, так и для ассоциативных массивов.

Вот пример числового:

$reindeers = [
1 => "Rudolph",
2 =>  "Dasher",
3 =>  "Dancer",
4 =>  "Prancer",
5 =>  "Vixen",
6 =>  "Comet",
7 =>  "Cupid",
8 =>  "Donner",
9 =>  "Blitzen"];
$first = array_key_first($reindeers); // $first is equal to 1
$last = array_key_last($reindeers); // $last is equal to 9

Вместо этого это пример ассоциативного массива:

$reindeers = [
"Rudolph" => 1,
"Dasher" => 2,
"Dancer" => 3,
"Prancer" => 4,
"Vixen" => 5,
"Comet" => 6,
"Cupid" => 7,
"Donner" => 8,
"Blitzen" => 9];
$first = array_key_first($reindeers); // $first is equal to "Rudolph"
$last = array_key_last($reindeers); // $last is equal to "Blitzen"

То же самое сработало бы для двух других функций, показанных в этой главе array_value_*

Просто для ясности, позвольте мне повторить,

В этих функциях было отказано с 18 нет и 15 да.

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

Вот почему:

$reindeers = [];
$first = array_value_first($reindeers ); // $first is equal to null
$last = array_value_last($reindeers );// $last is equal to null

Дополнительный вариант, с которым я сталкивался, просматривая форумы и общаясь с другими веб-разработчиками, заключался в том, чтобы вернуть кортеж, например [$key => $value].

Несмотря на то, что эта опция не будет доступна в новой версии, учитывая положительные отзывы, она может появиться со следующими RFC.

Поскольку это функция, которой раньше не существовало, проблем с обратной совместимостью не возникнет, единственная проблема может возникнуть, если вы создали и используете свою собственную версию array_key_first() и array_key_last().

Куки того же сайта
Развертывание безопасного приложения всегда должно быть в центре внимания каждого программиста.

Одна задача, с которой каждый из нас сталкивается ежедневно, — это снижение риска атак CSRF и утечки информации.

Приготовление на том же сайте объявляет, что файлы cookie должны отправляться только с запросом, инициированным из того же домена.

Это не официальный стандарт, но Google Chrome и несколько лучших фреймворков PHP уже реализуют его, тогда как Firefox и новые версии других фреймворков подтвердили, что они планируют это сделать.

Вот схема поддержки для файла cookie того же сайта с caniuse.com.

В настоящее время,

файлы cookie выдаются заголовком set-cookie,

Веб-разработчик может установить пару ключ-значение вместе с флагами для браузера, чтобы согласовать, должен ли быть доступен файл cookie или нет.

Такой способ позволяет получить уязвимый доступ к CSRF-атакам.

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

setcookie
setrawcookie
session_set_cookie_params

setcookie($name [,$value [,$expire [,$path [,$domain [, $secure [,$httponly [,$samesite]]]]]]]);

Было предложено два пути.

Добавление нового аргумента в функцию или предоставление массива опций для перемещения всех опций файлов cookie внутри.

Как это будет работать?

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

Они слабы и строги.

Файлы cookie, использующие Lax, будут доступны в запросе GET, поступающем из другого домена, в то время как Strict, наоборот, не будет доступен в запросе Get.

Например, заголовок при использовании более свободного флага будет выглядеть так:

Set-Cookie: ключ=значение; путь=/; домен=example.org; Только HTTP; Самесайт=слабый
Включить функции, которые повышают безопасность в коде, всегда кажется легкой задачей, но, как всегда, прежде чем принять решение о применении их в наших скриптах, мы должны правильно оценить все за и против нашего выбора.

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

Это означает, что в конечном итоге браузер сбросит флаг.

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

Мой личный совет — подождать, чтобы увидеть, что произойдет.

Если этот флаг станет более используемым и в конечном итоге станет стандартным, дерзайте!

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

Вывод
Как я и предполагал, этот новый релиз не содержит критических изменений,

так как это не новая версия, это правильно.

PHP делает небольшие, но непрерывные шаги, которые позволяют ему прогрессировать и улучшаться с течением времени, несмотря на то, что с годами люди перешли на более модные языки программирования.

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

Если содержание этих постов вам понравилось и вы не хотите ждать, полная статья в едином формате доступна в виде Kindle на Amazon по ссылке ниже.

передняя обложка-KDP.jpg
Этот пост в блоге является разделом книги Kindle «PHP 7.3 и его рождественские подарки”