Что нового в PHP 8

PHP 8 - следующая мажорная версия, примерная дата релиза конец 2020 года.

Итак, PHP 7.4 вышел и должен закончить эпохальную ветку седьмой версии. Столько много всего интересного было в ней реализовано, но разработчики PHP не стоят на месте и уже готовят 8 версию, которая будет содержать в себе много грандиозных вещей, о которых я и буду вас уведомлять по мере одобрения RFC или пулл-реквестов.  

PHP 8 - новая основная версия PHP, как ожидается, выйдет 26 ноября 2020 года. Так как PHP 8 все еще находится в активной разработке, то список новых функций, со временем, будет расти и меняться, его первая альфа ожидается 18 июня 2020 года.

JIT

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

Union Types 2.0 (Объединенные типы)

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

Type или null, используя специальный синтаксис "?Type"

array или Traversable, используя специальный тип iterable.

Однако произвольные объединенные типы в настоящее время не поддерживаются языком. Вместо этого необходимо использовать аннотации phpdoc, например, в следующем примере:

class Number {
    /**
     * @var int|float $number
     */
    private $number;
 
    /**
     * @param int|float $number
     */
    public function setNumber($number) {
        $this->number = $number;
    }
 
    /**
     * @return int|float
     */
    public function getNumber() {
        return $this->number;
    }
}

Объединенные типы указываются с использованием синтаксиса T1|T2|… и могут использоваться во всех позициях, где типы в настоящее время принимаются:

class Number {
    private int|float $number;
 
    public function setNumber(int|float $number): void {
        $this->number = $number;
    }
 
    public function getNumber(): int|float {
        return $this->number;
    }
}

Обратите внимание, что тип void не может быть частью типа объединения, так как он означает «вообще ничего-возвращаемого значения». Кроме того, nullable союзы могут быть написаны с использованием |null или с использованием существующей ? записи:

public function foo(Foo|null $foo): void;

public function bar(?Bar $bar): void;

Оператор nullsafe rfc

Если вы знакомы с оператором объединения c нулевым значением ( ?? ), думаю, что вы уже знакомы с его недостатками: он не работает с вызовами методов. Вместо этого вам нужны будут промежуточные проверки или надо будет полагаться на опциональных помощников, предоставляемых некоторыми фреймворками:

$startDate = $dateAsString = $booking->getStartDate();

$dateAsString = $startDate ? $startDate->asDateTimeString() : null;

С добавлением оператора nullsafe мы теперь можем иметь поведение методов, подобное слиянию null!

$dateAsString = $booking->getStartDate()?->asDateTimeString();

Именованные аргументы rfc

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

// Использование позиции аргументов:
array_fill(0, 100, 50);

// Использование наименований аргументов:
array_fill(start_index: 0, num: 100, value: 50);

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

htmlspecialchars($string, double_encode: false);
//то же самое что и
htmlspecialchars($string, ENT_COMPAT | ENT_HTML401, 'UTF-8', false);

Аттрибуты

Атрибуты, обычно известные в других языках, как аннотации или декораторы, предлагают способ добавлять метаданные в классы, без распарсивания докблоков. Широкое использование парсинга комментариев к документам пользователя показывает, что это очень востребованная функция сообщества. Атрибуты представляют собой специально отформатированный текст, заключенный в «<<» и «>>» путем повторного использования существующих токенов T_SL и T_SR.

Атрибуты могут применяться ко многим вещам в языке:

• функции (включая замыкания и короткие замыкания)
• классы (включая анонимные классы), интерфейсы, трейты
• константы класса
• свойства класса
• методы класса
• параметры функции/метода

Вот пока примерный взгляд из RFC:

use App\Attributes\ExampleAttribute;

<<ExampleAttribute>>
class Foo
{
    <<ExampleAttribute>>
    public const FOO = 'foo';
 
    <<ExampleAttribute>>
    public $x;
 
    <<ExampleAttribute>>
    public function foo(<<ExampleAttribute>> $bar) { }
}

<<PhpAttribute>>
class ExampleAttribute
{
    public $value;
 
    public function __construct($value)
    {
        $this->value = $value;
    }
}

Обратите внимание, что эта база Attribute вызывалась PhpAttributeв исходном RFC, но впоследствии была заменена другим RFC . Если вы хотите больше узнать как работают атрибуты, и как вы можете создать свой собственный, то можете прочитать об атрибутах в этом посте Атрибуты в PHP 8. 

Выражение соответствия v2

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

Вместо этого

switch (1) {
    case 0:
        $result = 'Foo';
        break;
    case 1:
        $result = 'Bar';
        break;
    case 2:
        $result = 'Baz';
        break;
}
 
echo $result;

Можно писать так:

echo match (1) {
    0 => 'Foo',
    1 => 'Bar',
    2 => 'Baz',
};

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

$result = match($input) {
    0 => "Какой-то Вывод",
    '1', '2', '3' => "Вывод условий 1,2,3",
};

Объявление свойств в конструкторе RFC

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

class Point {
    public float $x;
    public float $y;
    public float $z;
 
    public function __construct(
        float $x = 0.0,
        float $y = 0.0,
        float $z = 0.0,
    ) {
        $this->x = $x;
        $this->y = $y;
        $this->z = $z;
    }
}

Свойства повторяются 1) в объявлении свойства, 2) в параметрах конструктора и 3) два раза в назначении свойства. Кроме того, тип свойств так же повторяется дважды.

Этот RFC добавляет синтаксический сахар для создания объектов значений или объектов передачи данных. Вместо указания свойств класса и конструктора для них PHP теперь может объединять их в одно. В результате код сокращается до:

class Point { 
    public  function __construct ( 
        public float $x  =  0.0 , 
        public float $y  =  0.0 , 
        public float $z  =  0.0 , 
    )  { } 
}

Или еще пример, вместо этого:

class Money 
{
    public Currency $currency;
 
    public int $amount;
 
    public function __construct(
        Currency $currency,
        int $amount,
    ) {
        $this->currency = $currency;
        $this->amount = $amount;
    }
}

Теперь вы можете сделать это:

class Money 
{
    public function __construct(
        public Currency $currency,
        public int $amount,
    ) {}
}

Этот сокращенный код строго эквивалентен предыдущему примеру, но более лаконичен. Выбор синтаксиса взят из родственного языка Hack. Более подробно можно почитать в посте объявление свойств в конструкторе.

Новый тип возврата static

Хотя возвращение уже было возможно self, но до PHP 8 он не был допустимым типом возврата static . Учитывая динамически типизированный характер PHP, эта функция будет полезна для многих разработчиков.

class Foo
{
    public function method(): static
    {
        return new static();
    }
}

Новый тип mixed v2

С добавлением скалярных типов в PHP 7, обнуляемых в 7.1, объектов в 7.2 и, наконец, типов объединения в 8.0, люди, пишущие код PHP, могут явно объявлять информацию о типах для большинства параметров функции, возвращаемых функций, а также свойств класса. Однако в PHP не всегда поддерживаются типы, и, скорее всего, он всегда будет позволять опускать информацию о типах. Но это приводит к проблеме того, что ее значение неоднозначно, когда отсутствует информация о типе:

• Функция не возвращает ничего или null
• Мы ожидаем один из нескольких типов
• Мы ожидаем, тип, который не может быть подсказан в PHP

Из-за причин, приведенных выше, хорошо, что тип  mixed был наконец добавлен, Сам по себе mixed означает один из этих типов:

• array
• bool
• callable
• int
• float
• null
• object
• resource
• string

Обратите внимание, что mixed также может использоваться как параметр или тип свойства, а не только как тип возвращаемого значения. Также обратите внимание, что, поскольку mixed уже включает в себя null, это не может сделать его обнуляемым. Следующее вызовет ошибку:

// Fatal error: Mixed types cannot be nullable, null is already part of the mixed type.
function bar(): ?mixed {}

Throw выражения

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

// This was previously not possible since arrow functions only accept a single expression while throw was a statement.
$callable = fn() => throw new Exception();
 
// $value is non-nullable.
$value = $nullableValue ?? throw new InvalidArgumentException();
 
// $value is truthy.
$value = $falsableValue ?: throw new InvalidArgumentException();
 
// $value is only set if the array is not empty.
$value = !empty($array)
    ? reset($array)
    : throw new InvalidArgumentException();

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

$condition && throw new Exception();
$condition || throw new Exception();
$condition and throw new Exception();
$condition or throw new Exception();

Наследование приватных методов

Раньше PHP применял одинаковые проверки наследования для публичных, защищенных и приватных методов. Другими словами: private методы должны следовать тем же правилам подписи метода, что и protected и public методы. Это не имеет смысла, так как private методы не будут доступны дочерним классам.

Этот RFC изменил данное поведение, так что эти проверки наследования больше не выполняются для приватных методов. Кроме того, использование final private function также не имело смысла, поэтому теперь это вызовет предупреждение:

Warning: Private methods cannot be final as they are never overridden by other classes

Weak maps (Слабые карты)

Построенный на RFC слабых ссылок, который был добавлен в PHP 7.4, В PHP 8 WeakMap  добавляет ​​реализацию, в которой хранятся ссылки на объекты, которые не препятствуют сборке мусора этими объектами.

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

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

Вот как выглядят слабые карты, пример из RFC:

class Foo 
{
    private WeakMap $cache;
 
    public function getSomethingWithCaching(object $obj): object
    {
        return $this->cache[$obj]
           ??= $this->computeSomethingExpensive($obj);
    }
}

Использование ::class на объектах

Небольшая, но полезная новая функция: теперь можно использовать ::class на объектах, результат будет идентичен get_class():

//раньше
$bar = new Foo();
echo Foo::class;
//или
echo get_class($bar);
//'Foo'

//теперь можно будет так
$foo = new Foo();
echo $foo::class;
//'Foo'

Неподхваченные уловы

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

try {
    //Что-то идет не так
} catch (MySpecialException $exception) {
    Log::error("Что-то пошло не так");
}

Теперь вы можете сделать это:

try {
    // Что-то идет не так
} catch (MySpecialException) {
    Log::error("Что-то пошло не так");
}

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

Завершающая запятая в списках параметров

При вызове функции, в списках параметров все еще отсутствовала поддержка запятой. Теперь это разрешено в PHP 8, что означает, что вы можете делать следующее:

public function(
    string $parameterA,
    int $parameterB,
    Foo $objectfoo,
) {
    // …
}

Создать DateTime объекты из интерфейса

Вы уже можете создать DateTime объект из DateTimeImmutable объекта, используя DateTime::createFromImmutable($immutableDateTime), но наоборот было сложно. Добавление DateTime::createFromInterface() и DatetimeImmutable::createFromInterface() теперь позволяет получить обобщенный способ конвертировать DateTime и DateTimeImmutable объекты друг в друга.

DateTime::createFromInterface(DateTimeInterface $other);

DateTimeImmutable::createFromInterface(DateTimeInterface $other);

Новый Stringable интерфейс

Появится новый интерфейс Stringable, который автоматически добавляется в классы, которые реализуют магический метод __toString(), и нет необходимости реализовывать его вручную. 

У данного RFC две цели:

• разрешить использовать, string|Stringable чтобы выразить string|object-with-__toString()
• предоставить прямой путь обновления с PHP 7 до 8

class Foo
{
    public function __toString(): string
    {
        return 'foo';
    }
}

function bar(Stringable $stringable) { /* … */ }

bar(new Foo());
bar('abc');

Новая функция str_contains()

str_contains проверяет, содержится ли строка в другой строке, и возвращает логическое значение (true/false), независимо от того, была ли найдена строка. Некоторые могут сказать, что это давно пора, и нам, наконец, больше не нужно полагаться на strpos, чтобы узнать, содержит ли строка другую строку.

Вместо этого:

if (strpos('string with lots of words', 'words') !== false) { /* … */ }

Теперь вы можете сделать это

if (str_contains('string with lots of words', 'words')) { /* … */ }

Новые функции str_starts_with() и str_ends_with()

Две другие давно ожидаемые функции так же добавлены в ядро. str_starts_with() проверяет, начинается ли строка с другой строки, и возвращает логическое значение (true/false).

str_ends_with() логично проверяет, заканчивается ли строка другой строкой, и возвращает логическое значение (true/false). 

str_starts_with('haystack', 'hay'); // true
str_ends_with('haystack', 'stack'); // true

Как правило, эта функциональность достигается за счет использования существующих строковых функций, таких как substr, strpos/strrpos, strncmp или substr_compare(часто в сочетании с strlen), которые имеют различные недостатки. Что интересно,функциональность str_starts_with и str_ends_with настолько необходима, что ее поддерживают многие основные PHP-фреймворки, включая Symfony, Laravel, Yii, FuelPHP и Phalcon.

Новая функция fdiv

Новая функция  fdiv делает что-то подобное типа функций fmod и intdiv, что позволяет произвести деление на 0. Но вместо ошибок вы получите INF, -INF или NAN, в зависимости от случая.

Новая функция get_debug_type()

get_debug_type() возвращает тип переменной. Что-то похоже выдает gettype(), но get_debug_type() возвращает более полезный вывод для массивов, строк, анонимных классов и объектов. Например, вызов gettype() класса \Foo\Bar вернется object. Использование get_debug_type() вернет имя класса.

Полный список различий между get_debug_type()и gettype() можно найти в RFC.

Новая функцияp get_resource_id()

Ресурсы - это специальные переменные в PHP, ссылающиеся на внешние ресурсы. Например, соединение MySQL, или дескриптор файла.

Каждому из этих ресурсов присваивается идентификатор, хотя ранее единственным способом узнать, что это идентификатор, было преобразование ресурса в int:

$resourceId = (int) $resource;

PHP 8 добавляет функцию get_resource_id(), делая эту операцию более очевидной и безопасной для типов:

$resourceId = get_resource_id($resource);

Улучшение абстрактных методов трейтов 

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

trait Test {
    abstract public function test(int $input): int;
}

class UsesTrait
{
    use Test;

    public function test($input)
    {
        return $input;
    }
}

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

class UsesTrait
{
    use Test;

    public function test(int $input): int
    {
        return $input;
    }
}

Как бы то ни было, по словам автора RFC Никиты Попова , проверка подписи в настоящее время применяется только точечно:

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

Объектно-ориентированная альтернатива token_get_all()

Функция token_get_all() возвращает массив значений. Этот RFC добавляет класс PhpToken с методом PhpToken::getAll(). Эта реализация работает с объектами вместо простых значений, его легче читать, и потребляет меньше памяти.

Изменения синтаксиса переменных RFC

Унифицированный синтаксис переменной RFC устранил ряд несоответствий в синтаксисе переменной PHP. Этот RFC намеревается решить небольшую горстку пропущенных дел.

Тип аннотации для внутренних функций

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

Расширение ext-json всегда доступен

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

"Сломанные изменения"

PHP 8 - серьезное обновление и, следовательно, будут серьезные изменения. Лучшее, что можно сделать, это взглянуть на полный список критических изменений в документе ОБНОВЛЕНИЕ . Однако многие из этих критических изменений устарели в предыдущих версиях 7. *, поэтому, если вы были в курсе последних лет, не так уж сложно перейти на PHP 8.

Согласованные постоянные ошибки типов

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

Переклассифицированы предупреждения

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

• Undefined variable (Неопределенная переменная): Error исключение вместо уведомления
• Undefined array index (Неопределенный индекс массива): предупреждение вместо уведомления
• Division by zero (Деление на ноль): DivisionByZeroError исключение вместо предупреждения
• Attempt to increment/decrement property '%s' of non-object (Попытка увеличить/уменьшить свойство "%s" необъекта): Error исключение вместо предупреждения
• Attempt to modify property '%s' of non-object (Попытка изменить свойство "%s" необъекта): Error исключение вместо предупреждения
• Attempt to assign property '%s' of non-object (Попытка назначить свойство "%s" необъекта): Error исключение вместо предупреждения
• Creating default object from empty value (Создание объекта по умолчанию из пустого значения): Error исключение вместо предупреждения
• Trying to get property '%s' of non-object (Попытка получить свойство "%s" необъекта): предупреждение вместо уведомления
• Undefined property (Неопределенное свойство): %s::$%s: предупреждение вместо уведомления
• Cannot add element to the array as the next element is already occupied (Невозможно добавить элемент в массив, так как следующий элемент уже занят): Error исключение вместо предупреждения
• Cannot unset offset in a non-array variable (Невозможно сбросить смещение в переменной, не являющейся массивом): Error исключение вместо предупреждения
• Cannot use a scalar value as an array (Нельзя использовать скалярное значение в качестве массива): Error исключение вместо предупреждения
• Only arrays and Traversables can be unpacked (Только массивы и Traversables могут быть распакованы): TypeError исключение вместо предупреждения
• Invalid argument supplied for foreach() (Указан неверный аргумент для foreach ()): TypeError исключение вместо предупреждения
• Illegal offset type (Недопустимый тип смещения): TypeError исключение вместо предупреждения
• Illegal offset type in isset or empty (Недопустимый тип смещения в isset или empty): TypeError исключение вместо предупреждения
• Illegal offset type in unset (Недопустимый тип смещения в unset): TypeError исключение вместо предупреждения
• Array to string conversion (Преобразование массива в строку): предупреждение вместо уведомления
• Resource ID#%d used as offset, casting to integer (%d) (Идентификатор ресурса #%d, используемый в качестве смещения, приведение к целому числу (%d)): предупреждение вместо уведомления
• String offset cast occurred (Произошло приведение смещения строки): предупреждение вместо уведомления
• Uninitialized string offset: %d (Смещение неинициализированной строки: %d): предупреждение вместо уведомления
• Cannot assign an empty string to a string offset (Невозможно назначить пустую строку для смещения строки): Error исключение вместо предупреждения

Оператор @ больше не "глушит" фатальные ошибки

Вполне возможно, что это изменение может выявить ошибки, которые снова были скрыты до PHP 8. Обязательно установите display_errors=Off на своих производственных серверах!

Стандартный режим ошибки PDO

Из RFC: текущий режим ошибок по умолчанию для PDO - бесшумный. Это означает, что при возникновении ошибки SQL никакие ошибки или предупреждения не могут выдаваться и не генерируются исключения, если разработчик не реализует свою собственную явную обработку ошибок.

Этот RFC изменяет ошибку по умолчанию, которая изменится на PDO::ERRMODE_EXCEPTION.

Уровень сообщений об ошибках по умолчанию

Теперь по умолчанию в error_reporting уровень ошибок будет установлен в E_ALL вместо текущего  E_ALL & ~ E_NOTICE & ~ E_STRICT & ~ E_DEPRECATED. Это означает, что могут появиться много ошибок, которые ранее незаметно игнорировались, хотя, возможно, уже существовали до PHP 8.

Приоритет при конкатенации

Хотя это изменение уже устарело в PHP 7.4, теперь это изменение вступает в силу. Если бы вы написали что-то вроде этого:

echo "sum: " . $a + $b;

PHP ранее интерпретировал бы это так:

echo ("sum: " . $a) + $b;

PHP 8 сделает так, чтобы он интерпретировался так:

echo "sum: " . ($a + $b);

Более строгие проверки типов для арифметических и побитовых операторов

До PHP 8 можно было применять арифметические или побитовые операторы к массивам, ресурсам или объектам. Это больше не возможно и выдаст TypeError:

[] % [42];
$object + 4;

Имена в пространствах имен являются одним токеном rfc 

PHP используется для интерпретации каждой части пространства имен (разделенной обратной косой чертой \) как последовательности токенов. Этот RFC изменил это поведение, что означает, что теперь в пространствах имен можно использовать зарезервированные имена.

// In the library:
namespace iter\fn;
 
function operator($operator, $operand = null) { ... }
 
// In the using code:
use iter\fn;
 
iter\map(fn\operator('*', 2), $nums);

Более разумные числовые строки rfc

Система типов PHP пытается делать много умных вещей, когда встречает числа в строках. Этот RFC делает такое поведение более последовательным и понятным.

Более разумное сравнение чисел и строк rfc

Этот RFC исправляет очень странный случай в PHP, когда 0 == "foo" возвращает результат как true. Есть и другие крайние случаи, подобные этому, и этот RFC исправляет их.

Изменения подписи метода отражения

Три сигнатуры методов классов отражения были изменены:

ReflectionClass::newInstance($args);
ReflectionFunction::invoke($args);
ReflectionMethod::invoke($object, $args);

Теперь стали:

ReflectionClass::newInstance(...$args);
ReflectionFunction::invoke(...$args);
ReflectionMethod::invoke($object, ...$args);

В руководстве по обновлению указано, что если вы расширяете эти классы и по-прежнему хотите поддерживать как PHP 7, так и PHP 8, допускаются следующие подписи:

ReflectionClass::newInstance($arg = null, ...$args);
ReflectionFunction::invoke($arg = null, ...$args);
ReflectionMethod::invoke($object, $arg = null, ...$args);

Стабильная сортировка rfc

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

Стабильные сортировки полезны, прежде всего, при сортировке сложных данных только по некоторой части этих данных. Рассмотрим этот пример:

usort($users, function($user1, $user2) {
    return $user1->age <=> $user2->age;
});

Этот код сортирует пользователей по возрасту. В настоящее время порядок пользователей в одной возрастной группе будет произвольным. При стабильной сортировке исходный порядок объектов будет сохранен. Например, если $users уже был отсортирован по имени, то $users теперь будут отсортированы по возрасту первым и по имени вторым. Конечно, в этом случае можно было бы явно отсортировать по двум критериям:

usort($users, function($user1, $user2) {
    return $user1->age <=> $user2->age
        ?: $user1->name <=> $user2->name;
});

Однако это не всегда возможно, поскольку критерий, по которому данные были первоначально отсортированы, явно не сохраняется. Недавним случаем, с которым я столкнулся, был список git коммитов с метаданными, которые хранились в порядке push (но порядок push не был явно сохранен при каждом коммите).

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

$array  =  [ 
    'c'  =>  1 , 
    'd'  =>  1 , 
    'a'  =>  0 , 
    'b'  =>  0 , 
]; 
asort($array) ;
 
// При стабильной сортировке результат всегда: 
[ 'a'  =>  0 ,  'b'  =>  0 ,  'c'  =>  1 ,  'd'  =>  1 ]
 
// При нестабильной сортировке возможны также следующие результаты: 
[ 'b'  =>  0 ,  'a'  =>  0 ,  'c'  =>  1 ,  'd'  =>  1 ] 
[ 'a'  =>  0 ,  'b'  =>  0 ,  'd'  =>  1 ,  'c'  =>  1 ] 
[ 'b'  =>  0 ,  'a'  =>  0 ,  'd'  =>  1 ,  'c' =>  1 ]

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

Этот RFC предлагает сделать все функции сортировки PHP стабильными. Сюда входят rsort, usort, asort, arsort, uasort, ksort, krsort, uksort, array_multisort, а также соответствующие методы ArrayObject.

Неустранимая ошибка для несовместимых сигнатур методов rfc

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

Если класс реализует интерфейс, несовместимые сигнатуры методов вызывают фатальную ошибку. Согласно документации Object Interfaces:

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

Вот пример ошибки наследования с интерфейсом:

interface I {
	public function method(array $a);
}
class C implements I {
	public function method(int $a) {}
}

В PHP 7.4 приведенный выше код вызовет следующую ошибку:

Fatal error: Declaration of C::method(int $a) must be compatible with I::method(array $a) in /path/to/your/test.php on line 7

Функция в дочернем классе с несовместимой подписью выдала бы предупреждение.

class C1 {
	public function method(array $a) {}
}
class C2 extends C1 {
	public function method(int $a) {}
}

В PHP 7.4 приведенный выше код просто выдал бы предупреждение:

Warning: Declaration of C2::method(int $a) should be compatible with C1::method(array $a) in /path/to/your/test.php on line 7

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

Fatal error: Declaration of C2::method(int $a) must be compatible with C1::method(array $a) in /path/to/your/test.php on line 7

Устаревшее

Во время разработки PHP 7. * было добавлены предупреждения об устаревании, которые теперь полностью удалены в PHP 8.

• Устаревшее в PHP 7.2
• Устаревшее в PHP 7.3
• Устаревшее в PHP 7.4