Несколько недель назад русскоязычное PHP-сообщество проводило стрим по случаю выхода мажорной версии языка. По ходу трансляции зрители могли задать вопрос Никите Попову и Дмитрию Стогову, — а в конце те подключились и ответили на часть из них (остальные ответы мы опубликуем письменно, просто не успели уложить почти 100 вопросов в 40 минут — следите за постами pronskiy).



Вы можете посмотреть видеоверсию интервью тут.

Часть ответов уже разлетелась по чатам в виде цитат («Я все языки не люблю, но меньше других — Rust», «Когда вcе заговорили о PHP++, я задумался о PHP+-»), а остальные яркие моменты мы решили сложить в этот пост.

Каждый подзаголовок — это кратко переформулированный вопрос. Местами ответы приведены в усеченном виде, но без потери смысла.

Про нативные enum’ы в PHP

Никита Попов: Надеюсь, они будут в PHP 8.1: по крайней мере, есть план, как это будет выглядеть, и люди, которые над этим работают. Изначально будут достаточно простые, стандартные enum, которые будут имплементированы как специальные объекты. Каждый член enum — это отдельный класс.

Дмитрий Стогов: Зачем для этого классы? Почему не взять enum как набор констант и объединить их в один тип?

Никита Попов: Классы — чтобы можно было их как-то типизировать. Если enum – это числа 1, 2 ,3, то нельзя отличить числа от членов enum. Думаю, возможность типизации это главное, если ее нет, то можно просто использовать класс с константами.

Мы хотели бы все-таки, чтобы тип проверялся. Например, есть какой-то enum параметр, ты туда посылаешь просто integer или string — и тогда получаешь ошибку.

А не сделать ли PHP компилируемым?

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

По сути, у нас есть режим function для JIT, который можно рассматривать как ahead of time компилятор. Если включите его, то все, что загружается, будет сразу компилироваться. Но большого смысла я не вижу: вам все равно потребуется вся виртуальная машина, все библиотеки. Хотя, можно как в GraalVM – cделать какой-то урезанный пак.

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

Если вы заинтересованы не в производительности, а хотите код скомпилировать и давать людям только бинарник, чтобы они код не видели, – это другая задача. Я не вижу смысла делать open source продукт для людей, которые будут зарабатывать деньги, скрывая свои сорцы.

Перспективы асинхронности в PHP

Дмитрий Стогов: Большого выигрыша от асинхронности для всех в PHP я не вижу: это сложность, это очень узкое применение для определенного круга задач.

Добавить async/await – нет никаких проблем, это синтаксический сахар. Добавить файберы и корутины? В принципе, думаю, не так уж сложно.

Вопрос — кто этим займется и доведет ли он это до ума.

Я готов помогать.

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

Дмитрий Стогов: Вероятно, нам потребуется редизайнить stream layer. Если с ним разобраться, то все остальное будет проще. Анатоль Бельский пытался за это браться, но, потратив некоторое время, решил: «Ну его нафиг».

Есть уже планы, что добавить в 9-ку?

Никита Попов: Скорее, хотелось бы многое убрать. Например, reference если убрать, то все станет намного проще.

Дмитрий Стогов: Преобразование типов налету, сравнение строки с числом — вот от этого неплохо уйти уже в PHP 9, допустим.

Есть и мысли, что добавить. Например, вместо include’ов и require было бы хорошо сделать систему модулей настоящих, чтобы было понятно, какие классы и переменные откуда у нас приходят.

Это было бы очень круто, но это гигантская работа: просто понять, как все это должно выглядеть даже — в Jave модули выглядят ужасно, на мой взгляд. В Python… можно было бы сделать что-то такое, но с учетом, что у нас все динамично. Но может быть где-то есть что-то лучше.

Есть еще один момент, для меня достаточно интересный.

Если сейчас посмотреть на боттлнеки в PHP-парсере, например, это все обращения к массивам.

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

Это поможет, если мы обрабатываем матрицу какую-то на PHP: она будет плоской, как в C это представлено. Соответственно, работать с ней будет намного быстрее, особенно если мы используем это в JIT. Ничего сложного в этом нет, все «закладки» для этого уже заложены.

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

Сейчас много реализаций PSR-7. Может вам сделать что-то одно и затащить в ядро?

Никита Попов: Я считаю, что в ядро надо затаскивать вещи, которые важны для производительности. Это не тот случай.

Думаю, лучше, если вопросы request-response будут решаться в userland, — там можно соревноваться, делать какие-то изменения. Если мы загрузим это в ядро, тогда это навсегда: а если выяснится, что там что-то не то, сложно будет всем.

p.s. Спасибо Роману Пронскому за помощь в редактуре расшифровки. Читайте продолжение интервью, которое осталось за кадром стрима, в одном из следующих постов.