PHP Internals News: Episode 45: Language Evolution Overview Proposal
In this episode of “PHP Internals News” I chat with Nikita Popov (Twitter, GitHub, Website) about the Language Evolution Overview Proposal RFC.
The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news
Transcript
- Derick Rethans 0:16
-
Hi, I’m Derick. And this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 45. Today I’m talking with Nikita Popov yet again about a non technical RFC that he’s produced titled language evolution overview. Somewhere last year, there was a big discussion about P++, an alternative ID of how to deal with improving PHP as a language but also still think about how some other people already use PHP and I don’t really want to change how they currently use PHP. Like then I didn’t really have an episode about that because I’d like to keep politics out of this podcast, or definitely PHP’s internals politics. I do think that we realised at that moment that something did have to happen, because there’s not really policy about when we can add things, when we can remove things, and so on. So I was quite pleased to see that you have come up with a quite wordy RFC, not talking about anything technical, but more looking forward of were will see PHP in the near or medium future, I would say. What are your thoughts about making this RFC to start with?
- Nikita Popov 1:29
-
As you mentioned we had some pretty, let’s say heated discussions last year, concerning especially backwards incompatible changes. So there were a number of very, very contentious RFCs. One of them was the short opentags removal, and another one was the classification of undefined variable warnings. So whether those should throw or not throw, and well basic contention is this that PHP is a by now pretty old language, 25 years old. And we can all admit that it’s not the language with the best design. So it has evolved relatively organically with quite a few words, and the famous inconsistencies. And now we have this problem where we would like to resolve some of these long standing issues. Many of them are genuine problems that are introducing bugs in code, that reduce developer productivity. But at the same time, we have a huge amount of legacy code. So there are probably many hundreds of millions of lines of PHP code. And every time we do a backwards compatibility break, that code has to be updated, or more realistically, that code does not get updated and keeps hitting on old PHP version that, at some point also drops out of security support. And now the question is how can we fix the problems that PHP has, while still allowing this legacy code to update their PHP version. The general idea of how to fix this is to make certain backwards compatibility breaks opt in. By default, you just get the old behaviour, but you can specify in some way, exactly how it’s done doesn’t really matter at this point, that you want to opt into some kind of change or improvement.
- Derick Rethans 3:34
-
As one example being the strict types that have been introduced in PHP that you need to turn on with a switch with a declare switch.
- Nikita Popov 3:42
-
Strict types is really a great example because it has the important characteristic that has done per file. So you can turn on the strict types in one file and not affect any other code, at least in theory. So there are some edge cases, but I think like mostly you can just enable strict types in your library and you don’t affect any other library that the project uses. We would like to extend this concept. It should be possible that libraries can update to
Truncated by Planet PHP, read more at the original (another 29307 bytes)