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

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 44. Today I’m talking with Máté Kocsis about an RFC that he produced called write only properties. Hello, Máté. How’s it going?

Máté Kocsis 0:34

Yeah, fine. Thanks.

Derick Rethans 0:36

Would you mind introducing yourself a moment?

Máté Kocsis 0:38

My name is Máté Kocsis and I’m a software engineer at LogMeIn. I’ve been using PHP for 15 years now. And after having followed the mailing list for quite some time, I started contributing to the project last October, and now Write Once properties is my first RFC.

Derick Rethans 0:58

What is the concept of Write Once Properties?

Máté Kocsis 1:00

Write Once Properties can only be initialised, but not modified afterwards. So you can either define a default value for them, or assign them a value, but you can’t modify them later. So any other attempts to modify, unset, increment, or decrements them, would cause an exception to be thrown. Basically, this RFC would bring Java’s final properties, or C#’s, read only properties to PHP. However, contrary how these languages work, this RFC would allow lazy initialization. It means that these properties don’t necessarily have to be initialised until the object construction ends, so you can do that later in the object’s life cycle.

Derick Rethans 1:48

PHP already has constants, which are pretty much write only properties as long as they’re being defined in a class definition. How does differ?

Máté Kocsis 1:58

Yeah, it’s it’s the difference because, so you can assign these properties value in the constructor or anywhere. You don’t don’t have to define them a default value.

Derick Rethans 2:12

Okay, and of course constants have the other problem is that you can only set its values to constants, not necessarily to any sort of expressions, or the result of other method calls.

Unknown Speaker 2:22

So you can use objects, resources, any kind of property value here.

Derick Rethans 2:28 You mentioned C#’s read only properties. And you sort of mentioned them in the same breath as write ones properties for PHP. These seem like opposite things

Máté Kocsis 2:39

Not quite opposite, but there’s some distinction between the two. C sharp requires these properties to be initialised until the object construction ends. And this is very difficult to achieve in PHP. And now I’m using Nikita’s words: Object construction is a fuzzy term and you can be sure if, if the contractor is involved at all. For example, if you are using Doctrine or proxy manager, so we decided to allow lazy initialization, which means that you don’t have to assign these properties a value, you are free to do anytime when you want.

Derick Rethans 3:22

Although PHP 8 is no where near being released, I am keeping Xdebug’s master branch in line with PHP’s master branch. A few features have been added to PHP 8 that ended up breaking some code and tests, and some additions to the PHP DOM extension required work on upgrading test cases. When PHP 8 comes out, I am intending to have Xdebug ready to go with it. Hopefully, that will be Xdebug 3.0.

In February, a few new supporters signed up. They are:

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 43. Today I’m talking with Nikita Popov yet again about a few RFCs that he’s produced for PHP 8. Good morning, Nikita. How are you doing?

Nikita 0:34

Good morning, Derick. I’m doing great.

Derick Rethans 0:37

I’ve given up on introducing you because we’ve done this so many times. Now, you don’t need an introduction any more. The first RFC I wanted to talk about a little bit this morning is the abstract trait methods validation RFC. What are traits?

Nikita 0:51

We usually talk about traits as compiler assisted copy and paste. Basically, we just take all the methods and properties from a trait and copy them into the class that’s using the trait. That’s a bit over simplified, in particular, you can use multiple traits in the single class. And those traits might be defining the same method, in which case you have to resolve the conflict in some way. So that’s where you have these insteadof or use annotations to specify precedents and aliases.

Derick Rethans 1:23

Traits has been in PHP for quite a long time. What is now the problem that you’re trying to solve through this RFC?

Nikita 1:29

The problem is that traits are sometimes not self contained. So to give a specific example, we have in the logger PSR, we have a trait called logger trait, which has a bunch of methods like warning, error, info, notice, and so on. So just simple helper methods, which all called the log method with a specific log level and this trait only specified these helper methods but still requires the actual class to implement the log method. The way you’ll usually indicate that is by adding an abstract method to the trait. You have all the methods you actually want to provide by the trait. And you have a number of abstract methods that the trait itself requires to work. This already works fine, but the problem is just that these methods are not actually validated, or they are only inconsistently validated. Even though the trait specifies this abstract methods, you could implement it in the class with a completely different signature.

Derick Rethans 2:30

Okay, just like any signature?

Nikita 2:32

Just like any signature right. The method still has to be present in some way. But the signature can be completely different. Could also be like different method type, like a static method, or an instance method.

Derick Rethans 2:43

Just basically checks for the name is what you’re saying?

Nikita 2:46

Yeah, it only checks with the name.

Derick Rethans 2:49

Is this the only place, is this the only time where these abstract methods are not being validated. Or are there other situations where that could happen as well?

Nikita 2:57

No, I think thi