Занятное мини-интервью с основными контрибьюторами PHP 8
Несколько недель назад русскоязычное 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. Спасибо Роману Пронскому за помощь в редактуре расшифровки. Читайте продолжение интервью, которое осталось за кадром стрима, в одном из следующих постов.
