A fun mini interview with the main contributors of PHP 8

Several weeks ago, the Russian-speaking PHP community held a stream on the occasion of the release of the major version of the language. During the broadcast, viewers could ask a question to Nikita Popov and Dmitry Stogov, and at the end they connected and answered some of them (we will publish the rest of the answers in writing, we just did not have time to put almost 100 questions in 40 minutes – follow the posts of pronskiy).

You can watch the video version of the interview here

Some of the answers have already scattered around the chats in the form of quotes (“I don’t like all languages, but less than others – Rust”, “When everyone started talking about PHP ++, I thought about PHP + -“), and we decided to put the rest of the highlights in this post.

Each subheading is a short, reformulated question. In places the answers are given in truncated form, but without losing their meaning.

About native enums in PHP

Nikita Popov: Hopefully they will be in PHP 8.1: at least there is a plan for how it will look and the people who are working on it. Initially, there will be fairly simple, standard enum, which will be implemented as special objects. Each enum member is a separate class.

Dmitry Stogov: Why classes for this? Why not take an enum as a collection of constants and combine them into one type?

Nikita Popov: Classes – so that they can be typed somehow. If the enum is numbers 1, 2, 3, then you cannot distinguish numbers from enum members. I think the possibility of typing is the main thing, if it is not there, then you can simply use a class with constants.

We’d still like the type to be checked. For example, there is some kind of enum parameter, you just send an integer or string there – and then you get an error.

Shouldn’t PHP be compiled?

Dmitry Stogov: Nobody bothers to make a dynamically typed language compiled. It’s just that it will work exactly like an interpreter: check what type we have, and have code branches for every possible type.

Basically, we have function mode for JIT, which can be thought of as an ahead of time compiler. If you enable it, then everything that is loaded will be compiled immediately. But I don’t see much sense: you still need the entire virtual machine, all the libraries. Although, it is possible, as in GraalVM, to make some kind of stripped-down pack.

But this is a lot of work, and there will be no increase in productivity. Tracing JIT shows the best results, and it is only possible at runtime.

If you are not interested in performance, but want to compile the code and give people only a binary so that they don’t see the code, that’s another task. I see no point in making an open source product for people who will make money by hiding their sources.

Asynchronous Perspectives in PHP

Dmitry Stogov: I don’t see a big benefit from asynchrony for everyone in PHP: it’s complexity, it’s a very narrow application for a certain range of tasks.

Add async / await – no problem, it’s syntactic sugar. Add fibers and coroutines? In principle, I think it’s not so difficult.

The question is who will do it and whether he will bring it to mind.

I am ready to help.

Nikita Popov: There is someone working on this topic again. But the main problem is in a heap of synchronous code: this is the reason why Swoole is so popular in China, which replaces PDO and so on with a version that works asynchronously. But somehow I do not quite know if we want to have it at the kernel level. Because it will definitely make things more difficult.

Dmitry Stogov: We probably need to redesign the stream layer. If you deal with it, then everything else will be easier. Anatole Belsky tried to tackle it, but after spending some time, he decided: “Well, he nafig.”

There are already plans to add to the 9-ku?

Nikita Popov: Rather, I would like to remove a lot. For example, if you remove the reference, then everything will become much easier.

Dmitry Stogov: Converting types on the fly, comparing a string with a number – that’s a good idea to get away from this already in PHP 9, let’s say.

There are thoughts of what to add. For example, instead of includes and require, it would be nice to make the system of modules real, so that it is clear which classes and variables are coming from.

It would be very cool, but it’s a gigantic job: just to understand how all this should look even – in Jave, modules look terrible, in my opinion. In Python … it would be possible to do something like this, but taking into account that everything is dynamic here. But maybe there is something better somewhere.

There is one more point that is quite interesting for me.

If you now look at bottlenecks in a PHP parser, for example, these are all calls to arrays.

In JavaScript, you can find this: a single type of array, but in many cases it can work more optimally if it is represented in one way or another. That is, it is an adaptive array. For example, if there is an array of integers, then it can be represented as such. But as soon as something else is inserted there, it has to transform into something else.

This will help if we process a matrix of some kind in PHP: it will be flat, as represented in C. Accordingly, it will be much faster to work with it, especially if we use it in JIT. There is nothing complicated in this, all the “bookmarks” for this have already been laid.

This will not change anything for the user, it will just work faster.

There are many PSR-7 implementations now. Can you do one thing and drag it into the core?

Nikita Popov: I believe that things that are important for performance should be dragged into the kernel. This is not the case.

I think it’s better if request-response issues are resolved in userland, where you can compete, make some changes. If we load this into the kernel, then it’s forever: and if it turns out that something is wrong there, it will be difficult for everyone.

ps Thanks to Roman Pronsky for his help in editing the transcript. Read the continuation of the interview, which remained behind the scenes of the stream, in one of the following posts.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *