Php8

Перевод статьи подготовлен в преддверии старта курса Backend-разработчик на PHP

---

TL;DR

Компилятор Just In Time в PHP 8 реализован как часть расширения Opcache и призван компилировать операционный код в инструкции процессора в рантайме.

Это означает, что с JIT некоторые операционные коды не должны интерпретироваться Zend VM, такие инструкции будут выполняться непосредственно как инструкции уровня процессора.

JIT в PHP 8

Одной из наиболее комментируемых фич PHP 8 является компилятор Just In Time (JIT). Он на слуху во множестве блогов и сообществ вокруг него много шума, но пока я нашел не очень много подробностей о работе JIT в деталях.

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

Упрощая вещи: когда JIT работает должным образом, ваш код не будет выполняться через Zend VM, вместо этого он будет выполняться непосредственно как набор инструкций уровня процессора.

В этом вся идея.

Но чтобы лучше это понять, нам нужно подумать о том, как php работает внутри. Это не очень сложно, но требует некоторого введения.

Я уже писал статью с кратким обзором того, как работает php. Если вам покажется, что эта статья становится чересчур сложной, просто прочитайте ее предшественницу и возвращайтесь. Это должно немного облегчить ситуацию.

Как выполняется PHP-код?

Мы все знаем, что php интерпретируемый язык. Но что это на самом деле означает?

Всякий раз, когда вы хотите выполнить код PHP, будь то фрагмент или целое веб-приложение, вам придется пройти через интерпретатор php. Наиболее часто используемые из них PHP FPM и интерпретатор CLI. Их работа очень проста: получить код php, интерпретировать его и выдать обратно результат.

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

1. Код PHP читается и преобразуется в набор ключевых слов, известных как токены (Tokens). Этот процесс позволяет интерпретатору понять, в какой части программы написан каждый фрагмент кода. Этот первый шаг называется лексирование (Lexing) или токенизация (Tokenizing).
2. Имея на руках токены, интерпретатор PHP проанализирует эту коллекцию токенов и постарается найти в них смысл. В результате абстрактное синтаксическое дерево (Abstract Syntax Tree AST) генерируется с помощью процесса, называемого синтаксическим анализом (parsing). AST представляет собой набор узлов, указывающих, какие операции должны быть выполнены. Например, echo 1 + 1 должно фактически означать вывести результат 1 + 1 или, более реалистично, вывести операцию, операция 1 + 1.
3. Имея AST, например, гораздо проще понять операции и их приоритет. Преобразование этого дерева во что-то, что может быть выполнено, требует промежуточного представления (Intermediate Representation IR), которое в PHP мы называем операционный код (Opcode). Процесс преобразования AST в операционный код называется компиляцией.
4. Теперь, когда у нас есть опкоды, происходит самое интересное: выполнение кода! PHP имеет движок под названием Zend VM, который способен получать список опкодов и выполнять их. После выполнения всех опкодов программа завершается.

Чтобы сделать это немного нагляднее, я составил диаграмму:


Упрощенная схема процесса интерпретации PHP.

Достаточно прямолинейно, как вы можете заметить. Но здесь есть и узкое место: какой смысл лексировать и парсить код каждый раз, когда вы его выполняете, если ваш php-код может даже не меняется так часто?

В конце концов, нас интересуют только опкоды, верно? Правильно! Вот зачем существует расширение Opcache.

Расширение Opcache

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

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

Вот схема того же процесса с учетом расширения Opcache:


Поток интерпретации PHP с Opcache. Если файл уже был проанализирован, php извлекает для него кэшированный операционный код, а не анализирует его заново.

Это просто завораживает, как красиво пропускаются шаги лексирования, синтаксического анализа и компиляции.

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

Вы можете начать задумываться, а куда сюда можно прилепить JIT, верно?! По крайней мере я на это надеюсь, именно поэтому я и пишу эту статью

Что делает компилятор Just In Time?

Прослушав объяснение Зива в эпизоде подкастов PHP и JIT от PHP Internals News, мне удалось получить некоторое представление о том, что на самом деле должен делать JIT

Если Opcache позволяет быстрее получать операционный код, чтобы он мог переходить непосредственно к Zend VM, JIT предназначить заставить его работать вообще без Zend VM.

Zend VM это программа, написанная на C, которая действует как слой между операционным кодом и самим процессором. JIT генерирует скомпилированный код во время выполнения, поэтому php может пропустить Zend VM и перейти непосредственно к процессору. Теоретически мы должны выиграть в производительности от этого.

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

Реализация JIT в PHP использует библиотеку DynASM (Dynamic Assembler), которая отображает набор команд ЦП в конкретном формате в код сборки для многих различных типов ЦП. Таким образом, компилятор Just In Time преобразует операционный код в машинный код для конкретной архитектуры, используя DynASM.

Хотя одна мысль все-таки не давала мне покоя

Если предварительная загрузка способна парсить php-код в операционный перед выполнением, а DynASM может компилировать операционный код в машинный (компиляция Just In Time), почему мы, черт возьми, не компилируем PHP сразу же на месте, используя Ahead of Time компиляцию?!

Одна из мыслей, на которые меня натолкнул эпизода подкаста, заключалась в том, что PHP слабо типизирован, то есть часто PHP не знает, какой тип имеет переменная, пока Zend VM не попытается выполнить определенный опкод.

Это можно понять, посмотрев на тип объединения zend_value, который имеет много указателей на различные представления типов для переменной. Всякий раз, когда виртуальная машина Zend пытается извлечь значение из zend_value, она использует макросы, подобные ZSTR_VAL, которые пытаются получить доступ к указателю строки из объединения значений.

Например, этот обработчик Zend VM должен обрабатывать выражение меньше или равно (<=). Посмотрите, как он разветвляется на множество различных путей кода, чтобы угадать типы операндов.

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

Финальная компиляция после того, как типы были оценены, также не является хорошим вариантом, потому что компиляция в машинный код является трудоемкой задачей ЦП. Так что компиляция ВСЕГО во время выполнения плохая идея.

Как ведет себя компилятор Just In Time?

Теперь мы знаем, что не можем вывести типы, чтобы генерировать достаточно хорошую опережающую компиляцию. Мы также знаем, что компиляция во время выполнения стоит дорого. Чем же может быть полезен JIT для PHP?

Чтобы сбалансировать это уравнение, JIT PHP пытается скомпилировать только несколько опкодов, которые, по его мнению, того стоят. Для этого он профилирует коды операций, выполняемые виртуальной машиной Zend, и проверяет, какие из них имеет смысл компилировать. (в зависимости от вашей конфигурации).

Когда определенный опкод компилируется, он затем делегирует выполнение этому скомпилированному коду вместо делегирования на Zend VM. Это выглядит как на диаграмме ниже:


Поток интерпретации PHP с JIT. Если они уже скомпилированы, опкоды не выполняются через Zend VM.

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

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

Кстати, эта беседа Бенуа Жакемона о JIT от php ОЧЕНЬ помогла мне разобраться во всем этом.

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

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

Я надеюсь, что сейчас гораздо понятнее, ПОЧЕМУ все говорят, что большинство приложений php не получат больших преимуществ в производительности от использования компилятора Just In Time. И почему рекомендация Зива для профилирования и эксперимента с различными конфигурациями JIT для вашего приложения лучший путь.

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

Это потому, что JIT оптимизирует операции с процессором, а в настоящее время большинство php-приложений в большей степени завязаны на вводе/выводе, нежели на чем-либо еще. Не имеет значения, скомпилированы ли операции обработки, если вам все равно придется обращаться к диску или сети. Тайминги будут очень похожи.

Если только...

Вы делаете что-то не завязанное на ввод/вывод, например, обработку изображений или машинное обучение. Все, что не касается ввода/вывода, получит пользу от компилятора Just In Time. Это также причина, по которой люди сейчас говорят, что они склоняются больше к написанию нативных функций PHP, написанных на PHP, а не на C. Накладные расходы не будут разительно отличаться, если такие функции будут скомпилированы в любом случае.

Интересное время быть программистом PHP

Я надеюсь, что эта статья была полезна для вас, и вам удалось лучше разобраться, что такое JIT в PHP 8. Не стесняйтесь связываться со мной в твиттере, если вы хотите добавить что-то, что я мог забыть здесь, и не забудьте поделиться этим со своими коллегами-разработчиками, это, несомненно, добавит немного пользы вашим беседам!-- @nawarian

---

PHP: статические анализаторы кода

---

Пандемия повлияла на все бизнес-процессы, мы долго были в онлайне. Но 29 ноября PHP-разработчики смогут наконец встретиться офлайн в тёплой атмосфере, увидеть лучших спикеров PHP-вселенной, и задав им вопросы, разобрать актуальные кейсы и обсудить проблемы. PHP Russia 2020 пройдёт в Москве в гостинице Radisson Slavyanskaya. Приходите, если хотите получить ускорение и направление в развитии плюс набраться новых идей для своих проектов!

Александр Макаров расскажет о предстоящих активностях на конференции, о некоторых интерактивах и других нюансах. Александр эксперт в PHP, лидер фреймворка Yii, соавтор Yii 2 и представитель Yii в PHP-FIG. Кроме разработки фреймворка успел поработать в разных компаниях, таких как Skyeng, Wrike и Stay.com и перепробовать в бою целые поколения разных технологий.

Мы расспросили Александра как главу программного комитета по PHP Russia 2020 обо всех активностях и интересностях встречи.



Саша, что нас ждет на первой в этом году оффлайновой конференции?
Будет много интересных докладов :)

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

Мы отобрали доклады, в которых раскроем разные способы писать код: микросервисы, параллельная обработка, долгоживущие процессы. Покажем, как ещё вы можете использовать PHP, а с чем не стоит связываться, и разберем, как лучше оформить решения распространенных практических проблем. Поговорим, как организовать системную работу с legacy и справиться с техдолгом. Покажем, как legacy-проекты продолжают развиваться без радикального переписывания кода.

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

Будет, естественно, информация про PHP 8, и затронем интересную тему: она не совсем по PHP, а про написание плагинов для нашей любимой IDE PhpStorm.

Как и в прошлые разы, неплохо представлены такие лидеры PHP-разработки, как BADOO, Skyeng, ManyChat, Onliner, Lamoda, Авито и SuperJob. Они работают не только на PHP, но PHP это самое главное в их стеке. Необязательно все выступят с докладами, но представители этих компаний будут все.

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

Что необычного будет в этот раз?
Будет необычный формат с Дмитрием Стоговым из команды самого PHP. Он сделал JIT PHP.
Дмитрий приезжает не с докладом, а пообщаться в свободной форме с сообществом. Будет шанс задать ему любые вопросы не только про PHP 8 (и вообще про PHP), но и про остальную разработку, и даже чем он занимается в его свободное время. У Дмитрия неисчерпаемое множество тем для разговора, с ним очень интересно, а мы будем модерировать эту сессию вопросов и ответов.

Ещё в прошлый 2019-й офлайн мы попробовали такой замечательный формат как Unconference куда все желающие могли прийти и в блиц-формате рассказать про то, что они делают. Это тогда классно зашло, потому что были такие совершенно неожиданные рассказы, из которых потом получились и opensourse-бибилиотеки, и всякие крутые штуки. На онлайн-митапах, на которых мы сейчас иногда пересекаемся, до сих пор все с теплотой вспоминают эту встречу. Мы решили, что раз так, то этот формат забрасывать не надо, он классный. И мы повторим его в этом году.

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

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

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

То есть, если ничего не будет, то PHP-конференции не уйдет в онлайн?
Да. В прошлый раз она была онлайн, это было сильно, классно, но это показало, что онлайн это другая среда, совершенно другая штука. Классно то, что можно не привозя спикеров из очень дальних уголков, их всё-таки послушать. И просто и замечательно было в том, что в плане накладок ни мы, ни они ничего не теряли.

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

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

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

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

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

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

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

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

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

В этом году мы спросили региональные PHP-сообщества, хотят ли они выступать и есть ли что у них для митапов (чтобы с ними созвонились с конференции и послушали, что у них там делается в компаниях, проектах, и так далее). Они начали присылать, и мы смотрели две вещи: годная ли информация для докладов в принципе и достаточно ли она крутая для конференции.

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

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

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

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

Must learn PHP Tools:


PHP Engineer Things to Learn:

На конференции PHP Russia 2020 Александр Макаров выступит с докладом Поговорим про код в рамках лучших практик PHP. Вы узнаете принципы, позволяющие писать код, который ломается меньше. Например, о композиции и как её форсировать. О private по умолчанию и именованных конструкторах. О состоянии и иммутабельности, а также о цепочке вызовов и многом другом.

29 ноября мы встретимся в ламповом инфопространстве, чтобы наконец увидеть друг друга вживую. Здесь можно забронировать билет на PHP Russia 2020. Подключайтесь к telegram-сообществу, чтобы обсудить архитектурные вызовы и любые другие вопросы по PHP.

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

PHP 8 уже на этапе release candidate, версия RC 3 вышла 29 октября, а полноценный релиз назначен на 26 ноября. Так что пора взглянуть на новые возможности, которые нас ждут в PHP 8. График релизов можно посмотреть здесь. А официальное руководство по обновлению на новую версию лежит тут.

Добавлена поддержка типов union (RFC)

Тип union принимает значения разных других типов, а не только какого-то одного.

<?phpdeclare(strict_types=1); class Number {    private int|float $number;     public function setNumber(int|float $number): void {        $this->number = $number;    }     public function getNumber(): int|float {        return $this->number;    }} /** * We can pass both floats or integer values * to the number object. Try passing a string. */$number = new Number(); $number->setNumber(5); dump($number->getNumber()); $number->setNumber(11.54); dump($number->getNumber()); exit;

Добавлены WeakMap (RFC)

Слабые карты (weak maps) позволяют создавать связи между объектами и произвольными значениями (как и SplObjectStorage), при этом объекты, используемые в качестве ключей, не защищаются от сборщика мусора. Если сборщик уничтожает такой объект, тот просто удаляется из карты.

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

Если вы сделаете то же самое с массивом, то ссылки на объект сохранятся, что приведёт к утечке памяти.

<?phpdeclare(strict_types=1); class FooBar {    public WeakMap $cache;        public function __construct() {      $this->cache = new WeakMap();    }     public function getSomethingWithCaching(object $obj) {        return $this->cache[$obj] ??= $this->computeSomethingExpensive($obj);    }        public function computeSomethingExpensive(object $obj) {    dump("I got called");    return rand(1, 100);    }} $cacheObject = new stdClass; $obj = new FooBar;// "I got called" only will be printed once$obj->getSomethingWithCaching($cacheObject);$obj->getSomethingWithCaching($cacheObject); dump(count($obj->cache)); // When unsetting our object, the WeakMap frees up memoryunset($cacheObject); dump(count($obj->cache)); exit;

Новое исключение ValueError

В PHP 8 появился новый встроенный класс исключений ValueError. Он дополняет собой \Exception. PHP бросает такое исключение каждый раз, когда вы передаёте функции значение правильного типа, однако его нельзя использовать в этой операции. Раньше в таких случаях выдавалось предупреждение. Примеры:

<?phpdeclare(strict_types=1); /** * We pass an array to array_rand, * which is of the correct type. But * array_rand expects non-empty arrays. * * This throws a ValueError exception. */array_rand([], 0); /** * The depth argument for json_decode is a * valid integer, but it must be greater than 0 */json_decode('{}', true, -1);

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

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

<?phpdeclare(strict_types=1); class A {    public function method(int $many, string $parameters, $here) {     }}class B extends A {    public function method(...$everything) {        dd($everything);    }} $b = new B();$b->method('i can be overwritten!');exit;

Возвращаемый тип static (RFC)

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

<?phpdeclare(strict_types=1); class Test {    public function doWhatever(): static {        // Do whatever.        return $this;    }} exit;

Литерал имени класса для объекта (RFC)

Теперь можно извлекать имя класса объекта с помощью $object::class. Результат будет такой же, как в случае с get_class($object).

<?phpdeclare(strict_types=1); auth()->loginUsingId(1); dump(auth()->user()::class); // Or with a temporary variable$user = auth()->user(); dump($user::class);exit;

Настройки синтаксиса переменных (RFC)

New и instanceof теперь можно использовать с произвольными выражениями: new (выражение)(...$args) и $obj instanceof (выражение).

<?phpdeclare(strict_types=1); class Foo {}class Bar {}  $class = new (collect(['Foo', 'Bar'])->random()); dd($class); exit;

Интерфейс Stringable (RFC)

В PHP 8 появился новый интерфейс Stringable, который добавляется автоматически, как только класс реализует метод __toString. Вам не нужно явно реализовывать этот интерфейс.

<?phpdeclare(strict_types=1); class Foo {    public function __toString() {        return 'I am a class';    }} $obj = new Foo;dump($obj instanceof Stringable); exit;

Теперь трейты могут определять абстрактные приватные методы (RFC)

<?phpdeclare(strict_types=1);  trait MyTrait {    abstract private function neededByTheTrait(): string;     public function doSomething() {        return strlen($this->neededByTheTrait());    }} class TraitUser {    use MyTrait;     // This is allowed:    private function neededByTheTrait(): string { }     // This is forbidden (incorrect return type)    // private function neededByTheTrait(): stdClass { }     // This is forbidden (non-static changed to static)    // private static function neededByTheTrait(): string { }} exit;

throw теперь можно использовать как выражение (RFC)

Выражение throw теперь можно использовать там, где допускаются только выражения: в стрелочных функциях, coalesce-операторах тернарных условных операторах (ternary/elvis).

<?phpdeclare(strict_types=1); $callable = fn() => throw new Exception(); $nullableValue = null; // $value is non-nullable.$value = $nullableValue ?? throw new \InvalidArgumentException();  exit;

В параметрах списка теперь допускается опциональная висящая запятая (RFC)

По аналогии с висящей запятой в массивах, теперь можно определять её и в параметрах списка.

<?phpdeclare(strict_types=1); function method_with_many_arguments(    $a,     $b,    $c,    $d,) {    dump("this is valid syntax");} method_with_many_arguments(    1,    2,    3,    4,); exit;

Ловля исключений без сохранения в переменной (RFC)

Теперь можно писать catch (исключение) для ловли исключений без их сохранения в переменной.

<?phpdeclare(strict_types=1); $nullableValue = null; try {    $value = $nullableValue ?? throw new \InvalidArgumentException();} catch (\InvalidArgumentException) {    dump("Something went wrong");}  exit;

Добавлена поддержка типа mixed (RFC)

В PHP 8 появился новый тип mixed. Он может быть эквивалентен типам array, bool, callable, int, float, null, object, resource, string.

<?phpdeclare(strict_types=1); function debug_function(mixed ...$data) {    dump($data);} debug_function(1, 'string', []); exit;

Добавлена поддержка атрибутов

Есть несколько предложений по внедрению атрибутов в PHP 8:

• https://wiki.php.net/rfc/attributes_v2
• https://wiki.php.net/rfc/attribute_amendments
• https://wiki.php.net/rfc/shorter_attribute_syntax
• https://wiki.php.net/rfc/shorter_attribute_syntax_change

Это одно из крупнейших изменений в PHP 8. Возможно, сначала с ними не так легко будет разобраться. Если кратко, то атрибуты позволяют добавлять метаданные в PHP-функции, параметры, классы и т.д. Эти метаданные можно потом программно извлекать. Если в PHP 7 или ниже вам потребуется парсить doclock`и, атрибуты помогут обратиться к этой информации, глубоко интегрированной в сам PHP.

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

<?phpdeclare(strict_types=1);// First, we need to define the attribute. An Attribute itself is just a plain PHP class, that is annotated as an Attribute itself. #[Attribute]class ApplyMiddleware{    public array $middleware = [];     public function __construct(...$middleware) {        $this->middleware = $middleware;    }} // This adds the attribute to the MyController class, with the "auth" middleware as an argument. #[ApplyMiddleware('auth')]class MyController{    public function index() {}} // We can then retrieve all ApplyMiddleware attributes on our class using reflection// And read the given middleware arguments. $reflectionClass = new ReflectionClass(MyController::class); $attributes = $reflectionClass->getAttributes(ApplyMiddleware::class); foreach ($attributes as $attribute) {    $middlewareAttribute = $attribute->newInstance();    dump($middlewareAttribute->middleware);} exit;

Добавлена поддержка продвижения свойств конструктора (RFC)

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

<?phpdeclare(strict_types=1); class User {    public function __construct(        public int $id,        public string $name,    ) {}} $user = new User(1, 'Marcel'); dump($user->id);dump($user->name); exit;

Добавлена поддержка выражения match (RFC)

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

<?phpdeclare(strict_types=1); echo match (1) {    0 => 'Foo',    1 => 'Bar',    2 => 'Baz',}; exit;

Добавлена поддержка оператора nullsafe (?->) (RFC)

Когда результат левой части оператора равен null, исполнение всей цепочки останавливается, а её результат приравнивается к null. В противном случае цепочка ведёт себя как обычный оператор ->.

<?phpdeclare(strict_types=1); class User {    public function getAddress() {}} $user = new User(); $country = $user?->getAddress()?->country?->iso_code; dump($country); exit;

Добавлена поддержка именованных аргументов (RFC)

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

<?phpdeclare(strict_types=1); array_fill(start_index: 0, num: 100, value: 50); exit;

PHP, начиная с 7 версии, кардинально изменился. Код стал куда быстрее и надёжнее, и писать его стало намного приятнее. Но вот, уже релиз 8 версии! Ноябрь 26, 2020 примерно на год раньше, чем обещали сами разработчики. И всё же, не смотря на это, мажорная версия получилась особенно удачной. В этой статье я попытаюсь выложить основные приятные изменения, которые мы должны знать.

1. JIT

Как говорят сами разработчики, они выжали максимум производительности в 7 версии (тем самым сделав PHP наиболее шустрым среди динамических ЯПов). Для подальшего ускорения, без JIT-компилятора не обойтись. Справедливости ради, стоит сказать, что для веб-приложений использование JIT не сильно улучшает скорость обработки запросов (в некоторых случаях скорость будет даже меньше, чем без него). А вот, где нужно выполнять много математических операций там прирост скорости очень даже значительный. Например, теперь можно делать такие безумные вещи, как ИИ на PHP.
Включить JIT можно в настройках opcache в файле php.ini.
Подробнее 1 | Подробнее 2 | Подробнее 3

2. Аннотации/Атрибуты (Attributes)

Все мы помним, как раньше на Symfony код писался на языке комментариев. Очень радует, что такое теперь прекратится, и можно будет использовать подсказки любимой IDE, функция "Find usages", и даже рефакторинг!

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

Было очень много споров о синтаксисе для атрибутов, но приняли Rust-like синтаксис:

#[ORM\Entity]#[ORM\Table("user")]class User{    #[ORM\Id, ORM\Column("integer"), ORM\GeneratedValue]    private $id;    #[ORM\Column("string", ORM\Column::UNIQUE)]    #[Assert\Email(["message" => "The email '{{ value }}' is not a valid email."])]    private $email;}

Подробнее 1 | Атрибуты в Symfony

3. Именованые параметры (Named Arguments)

Если вы когда-либо видели код, где есть булевы параметры, то понимаете насколько он ужасен. Ещё хуже, когда этих параметров 8 штук, 6 из которых имеют значение по-умолчанию, а вам нужно изменить значение последнего параметра.

К примеру, код для использования библиотеки phpamqplib:

$channel->queue_declare($queue, false, true, false, false);// ...$channel->basic_consume($queue, '', false, false, false, false, [$this, 'consume']);

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

$channel->queue_declare($queue, durable: true, auto_delete: false);// ...$channel->basic_consume($queue, callback: [$this, 'consume']);

Ещё несколько примеров:

htmlspecialchars($string, default, default, false);// vshtmlspecialchars($string, double_encode: false);

Внимание! Можно также использовать ассоциативные массивы для именованых параметров (и наоборот).

$params = ['start_index' => 0, 'num' => 100, 'value' => 50];$arr = array_fill(...$params);

function test(...$args) { var_dump($args); }test(1, 2, 3, a: 'a', b: 'b');// [1, 2, 3, "a" => "a", "b" => "b"]

Подробнее

4. Оператор безопасного null (Nullsafe operator)

Null сам по себе не очень хорошая штука (даже очень плохая). Когда функция возвращает null, то в каждом месте, где идёт её вызов, программист обязан проверить на null. И это приводит к ужасным последствиям.

$session = Session::find(123);if ($session !== null) {    $user = $session->user;    if ($user !== null) {        $address = $user->getAddress();        if ($address !== null) {            $country = $address->country;        }    }}

По хорошему, должен быть метод Session::findOrFail, который будет кидать исключение в случае отсутствия результата. Но когда эти методы диктует фреймворк, то мы не можем ничего сделать. Единственное, это проверять каждый раз на null либо, где это уместно, использовать ?->.

Да, с оператором nullsafe код станет немного лучше, но всё же это не повод возвращать null.

$country = $session?->user?->getAddress()?->country;

Этот код нельзя назвать чистым, только лишь от части. Для чистого кода, нужно использовать шаблон Null Object, либо выбрасывать exception. Идеальным вариантом было б:

$country = $session->user->getAddress()->country;

Поэтому, если возможно с вашей стороны, никогда не возвращайте null (к Римлянам 12:18).

Также интересным моментом в использовании nullsafe есть то, что при вызове метода с помощью ?->, параметры будут обработаны только если объект не null:

function expensive_function() {    var_dump('will not be executed');}$foo = null;$foo?->bar(expensive_function());

5. Оператор выбора match (Match expression v2)

Для начала покажу код до и после:

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

VS

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

Как видим, это очень приятный оператор для выбора значений, который удобно заменяет switch.
Но есть очень важное отчилие switch от match: первый сравнивает нестрого ==, а во втором производится строгое === сравнение.

Наглядный пример различия:

switch ('foo') {    case 0:      $result = "Oh no!\n";      break;    case 'foo':      $result = "This is what I expected\n";      break;}echo $result; // Oh no!

VS

echo match ('foo') {    0 => "Oh no!\n",    'foo' => "This is what I expected\n",}; // This is what I expected

В PHP8 этот пример со switch работает по другому, далее рассмотрим это.

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

$result = match ($x) {    foo() => ...,    $this->bar() => ..., // bar() isn't called if foo() matched with $x    $this->baz => ...,    // etc.};

6. Адекватное приведение строки в число (Saner string to number comparisons)

Проблема

$validValues = ["foo", "bar", "baz"];$value = 0;var_dump(in_array($value, $validValues));// bool(true) ???

Это происходит потому, что при нестрогом == сравнении строки с числом, строка приводится к числу, то-есть, например (int)"foobar" даёт 0.

В PHP8, напротив, сравнивает строку и число как числа только если строка представляет собой число. Иначе, число будет конвертировано в строку, и будет производиться строковое сравнение.

Стоит отметить, что теперь выражение 0 == "" даёт false. Если у вас из базы пришло значение пустой строки и обрабатывалось как число 0, то теперь это не будет работать. Нужно вручную приводить типы.

Эти изменения относятся ко всем операциям, которые производят нестрогое сравнение:

• Операторы <=>, ==, !=, >, >=, <, <=.
• Функции in_array(), array_search(), array_keys() с параметром strict: false (то-есть по-умолчанию).
• Сотрировочные функции sort(), rsort(), asort(), arsort(), array_multisort() с флагом sort_flags: SORT_REGULAR (то-есть по-умолчанию).

Также, есть специальные значения которые при нестрогом сравнении дают true:

7. Constructor Property Promotion

Изначально идея позаимствована в языка-брата Hack. Она состоит в том, чтобы упростить инициализацию полей класса в конструкторе.

Вместо прописания полей класа, параметров конструктора, инициализации полей с помощью параметров, можно просто прописать поля параметрами конструктора:

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

Это эквивалентно:

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

С этим всё просто, так как это синтаксический сахар. Но интересный момент возникает при использовании вариативные параметры (их нельзя объявлять таким образом). Для них нужно по-старинке вручную прописать поля и установить их в конструкторе:

class Test extends FooBar {    private array $integers;    public function __construct(        private int $promotedProp,         Bar $bar,        int ...$integers,    ) {        parent::__construct($bar);        $this->integers = $integers;    }}

8. Новые функции для работы со строками (str_contains, str_starts_with, str_ends_with)

Функция str_contains проверяет, содержит ли строка $haystack строку $needle:

str_contains("abc", "a"); // truestr_contains("abc", "d"); // falsestr_contains("abc", "B"); // false // $needle is an empty stringstr_contains("abc", "");  // truestr_contains("", "");     // true

Функция str_starts_with проверяет, начинается ли строка $haystack строкой $needle:

$str = "beginningMiddleEnd";var_dump(str_starts_with($str, "beg")); // truevar_dump(str_starts_with($str, "Beg")); // false

Функция str_ends_with проверяет, кончается ли строка $haystack строкой $needle:

$str = "beginningMiddleEnd";var_dump(str_ends_with($str, "End")); // truevar_dump(str_ends_with($str, "end")); // false

Вариантов mb_str_ends_with, mb_str_starts_with, mb_str_contains нету, так как эти функции уже хорошо работают с мутльтибайтовыми символами.

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

9. Использование ::class на объектах (Allow ::class on objects)

Раньше, чтобы получить название класса, к которому принадлежит объект, нужно было использовать get_class:

$object = new stdClass;$className = get_class($object); // "stdClass"

Теперь же, можно использовать такую же нотацию, как и ClassName::class:

$object = new stdClass;var_dump($object::class); // "stdClass"

10. Возвращаемый тип static (Static return type)

Тип static был добавлен для более явного указания, что используется позднее статическое связывание (Late Static Binding) при возвращении результата:

class Foo {    public static function createFromWhatever(...$whatever): static {        return new static(...$whatever);    }}

Также, для возвращения $this, стоит указывать static вместо self:

abstract class Bar {    public function doWhatever(): static {        // Do whatever.        return $this;    }}

11. Weak Map

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

Интерфейс класса выглядит следующим образом:

WeakMap implements Countable , ArrayAccess , Iterator {    public __construct ( )    public count ( ) : int    public current ( ) : mixed    public key ( ) : object    public next ( ) : void    public offsetExists ( object $object ) : bool    public offsetGet ( object $object ) : mixed    public offsetSet ( object $object , mixed $value ) : void    public offsetUnset ( object $object ) : void    public rewind ( ) : void    public valid ( ) : bool}

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

class FooBar {    private WeakMap $cache;    public function getSomethingWithCaching(object $obj) {        return $this->cache[$obj] ??= $this->decorated->getSomething($obj);    }    // ...}

Подробнее можно почитать в документации.

12. Убрано возможность использовать левоассоциативный оператор (Deprecate left-associative ternary operator)

Рассмотрим код:

return $a == 1 ? 'one'     : $a == 2 ? 'two'     : $a == 3 ? 'three'     : $a == 4 ? 'four'              : 'other';

Вот как он всегда работал:

В 7.4 код как прежде, отрабатывал, но выдавался Deprecated Warning.
Теперь же, в 8 версии, код упадёт с Fatal error.

13. Изменение приоритета оператора конкатенации (Change the precedence of the concatenation operator)

Раньше, приоритет оператора конкатенации . был на равне с + и -, поэтому они исполнялись поочерёдно слева направо, что приводило к ошибкам. Теперь же, его приоритет ниже:

14. Удалены краткие открывающие php теги

В каждом скрипте, где в настоящее время используется короткий <? открывающий тег, нужно будет внести изменения и использовать стандартный тег <?php.

Это не касается тега <?=, так как он, начиная с 5.4 всегда доступен.

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

Объекты, которые реализуют метод __toString, неявно реализуют этот интерфейс. Сделано это в большей мере для гарантии типобезопасности. С приходом union-типов, можно писать string|Stringable, что буквально означает "строка" или "объект, который можно преобразовать в строку". В таком случае, объект будет преобразован в строку только когда уже не будет куда оттягивать.

interface Stringable{    public function __toString(): string;}

Рассмотрим такой код:

class A{    public function __toString(): string     {        return 'hello';    }}function acceptString(string $whatever) {    var_dump($whatever);}acceptString(123.45); // string(6) "123.45"acceptString(new A()); // string(5) "hello"

Здесь функция acceptString принимает строку, но что если нам нужно конкретно объект, что может быть преобразован в строку, а не что-либо иное. Вот тут нам поможет интерфейс Stringable:

function acceptString(Stringable $whatever) {    var_dump($whatever);    var_dump((string)$whatever);}// acceptString(123.45); /*TypeError*/acceptString(new A()); /*object(A)#1 (0) {}string(5) "hello"*/

16. Теперь throw это выражение

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

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

Подробнее можно почитать здесь.

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

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

Сюда входят sort, rsort, usort, asort, arsort, uasort, ksort, krsort, uksort, array_multisort, а также соответствующие методы в ArrayObject.

18. Возможньсть опустить переменную исключения (non-capturing catches)

Раньше, даже если переменная исключения не использовалась в блоке catch, её всё равно нужно быто объявлять (и IDE подсвечивала ошибку, что переменная нигде не используется):

try {    changeImportantData();} catch (PermissionException $ex) {    echo "You don't have permission to do this";}

Теперь же, можно опустить переменную, если никакая дополнительная информация не нужна:

try {    changeImportantData();} catch (PermissionException) { // The intention is clear: exception details are irrelevant    echo "You don't have permission to do this";}

19. Обеспечение правильной сигнатуры магических методов (Ensure correct signatures of magic methods):

Когда были добавлены type-hints в php, оставалась возможность непавильно написать сигнатуру для магических методов.
К примеру:

class Test {    public function __isset(string $propertyName): float {        return 123.45;    }}$t = new Test();var_dump(isset($t)); // true

Теперь же, всё жёстко контролируется, и допустить ошибку сложнее.

Foo::__call(string $name, array $arguments): mixed;Foo::__callStatic(string $name, array $arguments): mixed;Foo::__clone(): void;Foo::__debugInfo(): ?array;Foo::__get(string $name): mixed;Foo::__invoke(mixed $arguments): mixed;Foo::__isset(string $name): bool;Foo::__serialize(): array;Foo::__set(string $name, mixed $value): void;Foo::__set_state(array $properties): object;Foo::__sleep(): array;Foo::__unserialize(array $data): void;Foo::__unset(string $name): void;Foo::__wakeup(): void;

20. Включить расширение json по-умолчанию (Always available JSON extension)

Так как функции для работы с json постоянно используются, и нужны чуть ли не в каждом приложении, то было принято решение включить ext-json в PHP по-умолчанию.

21. Более строгие проверки типов при для арифметических и побитовых операторов (Stricter type checks for arithmetic/bitwise operators)

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

var_dump([] % [42]);

Что должен вывести этот код? Здесь непредсказуемое поведение (будет 0). Всё потому, что большинство арифметических операторов не должны применятся на массивах.

Теперь, при использовании операторов +, -, *, /, **, %, <<, >>, &, |, ^, ~, ++, -- будет вызывать исключение TypeError для операндов array, resource и object.

22. Валидация абстрактных методов в трейтах (Validation for abstract trait methods)

До восьмой версии, можно было писать что-то вроде:

trait T {    abstract public function test(int $x);}class C {    use T;    // Allowed, but shouldn't be due to invalid type.    public function test(string $x) {}}

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

trait MyTrait {    abstract private function neededByTheTrait(): string;    public function doSomething() {        return strlen($this->neededByTheTrait());    }}class TraitUser {    use MyTrait;    // This is allowed:    private function neededByTheTrait(): string { }    // This is forbidden (incorrect return type)    private function neededByTheTrait(): stdClass { }    // This is forbidden (non-static changed to static)    private static function neededByTheTrait(): string { }}

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

23. Объединения типов (Union Types 2.0)

Рассмотрим код:

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;    }}

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

Теперь же, можно прописать тип int|float (или любой другой) явно, чтобы обеспечить корректность работы модуля:

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

А также, код становится намного чище.
Как вы уже могли заметить, типы-объединения имеют синтаксис T1|T2|... и могут быть использованы во всех местах, где можно прописать type-hints.

Некоторые оговорки:

• Тип void не может быть частью объединения.
• Чтобы обозначить отсутствие результата, можно объявить "Nullable union type", который имеет следующий синтаксис: T1|T2|null.
• Тип null не может быть использован вне объединения. Вместо него стоит использовать void.
• Существует также псевдотип false, который по историческим причинам уже используется некоторыми функциями в php. С другой стороны, не существует тип true, так как он нигде не использовался ранее.

Типы полей класса инвариантны, и не могут быть изменены при наследовании.
А вот с методами всё немного интересней:

1. Параметры методов можно расширить, но нельзя сузить.
2. Возвращаемые типы можно сузить, но нельзя расширить.

Вот как это выглядит в коде:

class Test {    public function param1(int $param) {}    public function param2(int|float $param) {}    public function return1(): int|float {}    public function return2(): int {}}class Test2 extends Test {    public function param1(int|float $param) {} // Allowed: Adding extra param type    public function param2(int $param) {}       // FORBIDDEN: Removing param type    public function return1(): int {}           // Allowed: Removing return type    public function return2(): int|float {}     // FORBIDDEN: Adding extra return type}

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

class A {}class B extends A {}class Test {    public function param1(B|string $param) {}    public function param2(A|string $param) {}    public function return1(): A|string {}    public function return2(): B|string {}}class Test2 extends Test {    public function param1(A|string $param) {} // Allowed: Widening union member B -> A    public function param2(B|string $param) {} // FORBIDDEN: Restricting union member A -> B    public function return1(): B|string {}     // Allowed: Restricting union member A -> B    public function return2(): A|string {}     // FORBIDDEN: Widening union member B -> A}

Интереснее становится когда strict_types установлен в 0, то-есть по-умолчанию. Например, функция принимает int|string, а мы передали ей bool. Что в результате должно быть в переменной? Пустая строка, или ноль? Есть набор правил, по которым будет производиться приведение типов.

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

1. int;
2. float;
3. string;
4. bool;

Так вот, будет перебираться этот список с типами, и для каждого проверяться: Если тип существует в объединении, и значение может быть приведёно к нему в соответствии с семантикой PHP, то так и будет сделано. Иначе пробуем следующий тип.

Как исключение, если string должен быть приведён к int|float, то сравнение идёт в первую очередь в соответствии с семантикой "числовых строк". К примеру, "123" станет int(123), в то время как "123.0" станет float(123.0).

К типам null и false не происходит неявного преобразования.

Таблица неявного приведения типов:

Типы полей и ссылки

class Test {    public int|string $x;    public float|string $y;}$test = new Test;$r = "foobar";$test->x =& $r;$test->y =& $r;// Reference set: { $r, $test->x, $test->y }// Types: { mixed, int|string, float|string }$r = 42; // TypeError

Здесь проблема в том, что тип устанавливаемого значения не совместим с объявленными в полях класса. Для Test::$x это могло быть int(42), а для Test::$y float(42.0). Так как эти значения не эквивалентны, то невозможно обеспечить единую ссылку, и TypeError будет сгенерирован.

24. Тип mixed (Mixed Type v2)

Был добавлен новый тип mixed.
Он эквивалентен типу array|bool|callable|int|float|object|resource|string|null.
Когда параметр объявлен без типа, то его тип это mixed.
Но стоит отметить, что если функция не объявляет возвращаемого значения, то это не mixed, а mixed|void. Таким образом, если функция гарантировано должна что-то возвращать, но тип результата не известен заранее, то стоит написать его mixed.

При наследовании действуют следующие правила:

class A{    public function bar(): mixed {}}class B extends A{    // return type was narrowed from mixed to int, this is allowed    public function bar(): int {}}

class C{    public function bar(): int {}}class D extends C{    // return type cannot be widened from int to mixed    // Fatal error thrown    public function bar(): mixed {}}

Подробнее можно почитать здесь

Где смотреть новые фичи

Более информации про новые функции в PHP можно посмотреть на rfc watch.

IMHO хорошие идеи для PHP

• Неизменные (постоянные, надёжные) значения. Когда это внедрят в PHP код станет намного более безопасным и удобочитаемым.

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

Вот пример проблемного кода. Со временем значение изменяется, и при добавлении ещё какой-либо обработки велика вероятность сломать что-то на следующих строках:

$invoice = getInvoice();$invoice = loadDependencies($invoice);$invoice = formatInvoice($invoice);// hm... how do I access initial $invoice now?return $invoice;

Я вижу как минимум 4 недостатка в этом коде:

1. Никогда точно не знаешь что в переменной;
2. Невозможность использовать уже перезаписанное значение где-то дальше в коде;
3. Неустойчивость к изменениям если производиться копипаст большой части кода с такими-же переменными где-то во вложенном if, тогда ночь отладки обеспеченна.
4. Каждый раз нужно писать знак $ перед $переменной. Да, это спорно, но ведь без долларов проще читать код. Возьмите какого-либо джависта, что он скажет про ваш код? Уххх как много долларов!

Вот каким мог быть этот код:

invoice = getInvoice();invoiceWithDependencies = loadDependencies(invoice);invoiceFormatted = formatInvoice(invoiceWithDependencies);// someAnotherAction(invoice);return invoiceFormatted;

Значения, что содержатся в invoice, invoiceWithDependencies, invoiceFormatted не могут быть перезаписаны. Да, и теперь мы точно знаем что и где хранится.

function printArr(array arr) {    foreach (arr as firmValue) {        print strtr(            "Current value is {current}. +1: {next}",             [                '{current}' => firmValue,                 '{next}'    => firmValue + 1            ]        );    }}

• Перегрузка операторов. Из 66 разработчиков, 28 проголосовали против, и поэтому, не смотря на то, что идея уже была реализована, предложение было отклонено. Думаю стоит поднять дискуссию на эту тему.
• Разрешить вычисление в константных выражениях. Как по мне, этого очень не хватает.
  Вот пример кода, где это очень полезно:

use Spatie\ModelStates\State;abstract class OrderStatus extends State{    public static string $name = static::getName();    abstract protected function getName(): string;}

Как видим, при первом обращении к $name, будет вызван метод getName финального класса. Это дает нам возможность настраивать какие значения будут попадать в поля в зависимости от каких-либо условий. А в данном примере это использовано с шаблоном "Template Method", и финальные классы обязаны предоставить нам значение для поля.

Сейчас многие фреймворки имеют значени по-умолчанию для большинства конфигураций в своих классах. Проблема с таким подходом заключается в том, что мы можем предоставить только примитивное значение. Никаких вызовов функций не разрешено. А что если мы хотим вызвать хелпер config для предоставления конфигурации, которая задаётся в поле класса? Тогда у нас проблемы, и нужно переопределять конструктор, где уже задавать значение поля. Хорошо, когда конструктор не имеет много параметров. А что, если там много параметров (к примеру, 7)? Тогда для простого создания поля, нужно 20 дополнительных бесполезных строк кода. И выглядит это ещё как уродливо!

Просто сравните это:

    protected string $whatever = $this->doCalculate();

И это:

    public function __construct(        array $query = [],        array $request = [],        array $attributes = [],        array $cookies = [],        array $files = [],        array $server = [],        $content = null    ) {        parent::__construct(            $query,            $request,            $attributes,            $cookies,            $files,            $server,            $content        );        $this->whatever = $this->doCalculate();    }

Почему мы должны инициализировать поле в конструкторе, если оно не зависит от его параметров? Как по мне, мы не должны.