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 65. Today I’m talking with Dan Ackroyd about an RFC that he’s been working on together with Ilija Tovilo. Hello, Dan, would you please introduce yourself?

Hi Derick, my name is Daniel, I’m the maintainer of the imagick extension, and I occasionally help other people with RFCs.

And in this case, you helped out Ilija with the null safe operator RFC.

It’s an idea that’s been raised on internals before but has never had a very strong RFC written for it. Ilija did the technical implementation, and I helped him write the words for the RFC to persuade other people that it was a good idea.

Ilija declined to be talking to me.

He sounds very wise.

Let’s have a chat about this RFC. What is the null safe operator?

Imagine you’ve got a variable that’s either going to be an object or it could be null. The variable is an object, you’re going to want to call a method on it, which obviously if it’s null, then you can’t call a method on it, because it gives an error. Instead, what the null safe operator allows you to do is to handle those two different cases in a single line, rather than having to wrap everything with if statements to handle the possibility that it’s just null. The way it does this is through a thing called short circuiting, so instead of evaluating whole expression. As soon as use the null safe operator, and when the left hand side of the operator is null, everything can get short circuited, or just evaluates to null instead.

So it is a way of being able to call a methods. A null variable that can also represent an object and then not crash out with a fatal error

That’s what you want is, if the variable is null, it does nothing. If a variable was the object, it calls method. This one of the cases where there’s only two sensible things to do, having to write code to handle the two individual cases all the time just gets a bit tedious to write the same code all the time.

Especially when you have lots of nested calls I suppose.

That’s right. It doesn’t happen too often with code, but sometimes when you’re using somebody else’s API, where you’re getting structured data back like in an in a tree, it’s quite possible that you have the first object that might be null, it’s not null, it’s going to point to another object, and the object could be null so and so so down the tree of the structure of the data. It gets quite tedious, just wrapping each of those possible null variables with a if not null.

The RFC as an interesting ex

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 66. Today I’m talking with Nikita Popov about an RFC that he’s made, called namespace names as token. Hello Nikita, how are you this morning?

I’m fine Derick, how are you?

I’m good as well, it’s really warm here two moments and only getting hotter and so.

Same here. Same here.

Yeah, all over Europe, I suppose. Anyway, let’s get chatting about the RFC otherwise we end up chatting about the weather for the whole 20 minutes. What is the problem that is RFC is trying to solve?

So this RFC tries to solve two problems. One is the original one, and the other one turned up a bit later. So I’ll start with the original one. The problem is that PHP has a fairly large number of different reserved keyword, things like class, like function, like const, and these reserved keywords, cannot be used as identifiers, so you cannot have a class that has the name list. Because list is also a keyword that’s used for array destructuring. We have some relaxed rules in some places, which were introduced in PHP 7.0 I think. For example, you can have a method name, that’s a reserved keyword, so you can have a method called list. Because we can always disambiguate, this versus the like real list keyword. But there are places where you cannot use keywords and one of those is inside namespace names.

So to give a specific example of code that broke, and that was my, my own code. So, I think with PHP 7.4, we introduced the arrow functions with the fn keyword to work around various parsing issues. And I have a library called Iter, which provides various generator based iteration functions. And this library has a namespace Iterfn. So Iter backslash fn. Because it has this fn keyword as part of the name, this library breaks in PHP 7.4. But the thing is that this is not truly unnecessary breakage. Because if we just write Iter backslash fn, there is no real ambiguity there. The only thing this can be is a namespace name, and similarly if you import this namespace then the way you actually call the functions is using something like fn backslash operator. Now once again you have fn directly before a backslash so there is once again no real ambiguity. Where the actual ambiguity comes from is that we don’t treat namespace names as a single unit. Instead, we really do treat them as the separate parts. First one identifier than the backslash, then other identifier, then the backslash, and so on. And this means that our reserved keyword restrictions apply to each individual part. So the whole thing.

The original idea behind this proposal was actually to go quite a bit further. The proposal is that instead of treating all of these segments of the name separately, we treat it as a single unit, as a single token. And that also means that it’s okay to use reserved keywords inside it. As long as like the whole name, taken together is not a reserved keyword. The idea of the RFC was to, like, reduce the impact of additional reserved keywords, introduc