PHP Internals News: Episode 76: Deprecate null, and Array Unpacking PHP Internals News
-
- Teknologi
PHP Internals News: Episode 76: Deprecate null, and Array Unpacking
London, UK
Thursday, February 18th 2021, 09:04 GMT
In this episode of "PHP Internals News" I chat with Nikita Popov (Twitter, GitHub, Website) about two RFCs: Deprecate passing null to non-nullable arguments of internal functions, and Array Unpacking with String Keys.
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:14
Hi I'm Derick. Welcome to PHP internals news, a podcast dedicated to explain the latest developments in the PHP language. This is Episode 76. In this episode, I'm talking with Nikita Popov about a few more RFCs that he has been working on over the past few months. Nikita, would you please introduce yourself.
Nikita Popov 0:34
Hi, I'm Nikita. I work on PHP core development on behalf of JetBrains.
Derick Rethans 0:39
In the last few PHP releases PHP is handling of types with regards to internal functions and user land functions, has been getting closer and closer, especially with types now. But there's still one case where type mismatches behave differently between internal and user land functions. What is this outstanding difference?
Nikita Popov 0:59
Since PHP 8.0 on the remaining difference is the handling of now. So PHP 7.0 introduced scalar types for user functions. But scalar types already existed for internal functions at that time. Unfortunately, or maybe like pragmatically, we ended up with slightly different behaviour in both cases. The difference is that user functions, don't accept null, unless you explicitly allow it using nullable type or using a null default value. So this is the case for all user types, regardless of where or how they occur as parameter types, return values, property types, and independent if it's an array type or integer type. For internal functions, there is this one exception where if you have a scalar type like Boolean, integer, float, or a string, and you're not using strict types, then these arguments also accept null values silently right now. So if you have a string argument and you pass null to it, then it will simply be converted into an empty string, or for integers into zero value. At least I assume that the reason why we're here is that the internal function behaviour existed for a long time, and the use of that behaviour was chosen to be consistent with the general behaviour of other types at the time. If you have an array type, it also doesn't accept now and just convert it to an empty array or something silly like that. So now we are left with this inconsistency.
Derick Rethans 2:31
Is it also not possible for extensions to check whether null was passed, and then do a different behaviour like picking a default value?
Nikita Popov 2:40
That's right, but that's a different case. The one I'm talking about is where you have a type like string, while the one you have in mind is where you effectively have a type like string or null.
Derick Rethans 2:51
Okay.
Nikita Popov 2:52
In that case, of course, accepting null is perfectly fine.
Derick Rethans 2:56
Even though it might actually end up being different defaults.
Nikita Popov 3:01
Yeah. Nowadays we would prefer to instead, actually specify a default value. Instead of using null, but using mull as a default and then ass
PHP Internals News: Episode 76: Deprecate null, and Array Unpacking
London, UK
Thursday, February 18th 2021, 09:04 GMT
In this episode of "PHP Internals News" I chat with Nikita Popov (Twitter, GitHub, Website) about two RFCs: Deprecate passing null to non-nullable arguments of internal functions, and Array Unpacking with String Keys.
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:14
Hi I'm Derick. Welcome to PHP internals news, a podcast dedicated to explain the latest developments in the PHP language. This is Episode 76. In this episode, I'm talking with Nikita Popov about a few more RFCs that he has been working on over the past few months. Nikita, would you please introduce yourself.
Nikita Popov 0:34
Hi, I'm Nikita. I work on PHP core development on behalf of JetBrains.
Derick Rethans 0:39
In the last few PHP releases PHP is handling of types with regards to internal functions and user land functions, has been getting closer and closer, especially with types now. But there's still one case where type mismatches behave differently between internal and user land functions. What is this outstanding difference?
Nikita Popov 0:59
Since PHP 8.0 on the remaining difference is the handling of now. So PHP 7.0 introduced scalar types for user functions. But scalar types already existed for internal functions at that time. Unfortunately, or maybe like pragmatically, we ended up with slightly different behaviour in both cases. The difference is that user functions, don't accept null, unless you explicitly allow it using nullable type or using a null default value. So this is the case for all user types, regardless of where or how they occur as parameter types, return values, property types, and independent if it's an array type or integer type. For internal functions, there is this one exception where if you have a scalar type like Boolean, integer, float, or a string, and you're not using strict types, then these arguments also accept null values silently right now. So if you have a string argument and you pass null to it, then it will simply be converted into an empty string, or for integers into zero value. At least I assume that the reason why we're here is that the internal function behaviour existed for a long time, and the use of that behaviour was chosen to be consistent with the general behaviour of other types at the time. If you have an array type, it also doesn't accept now and just convert it to an empty array or something silly like that. So now we are left with this inconsistency.
Derick Rethans 2:31
Is it also not possible for extensions to check whether null was passed, and then do a different behaviour like picking a default value?
Nikita Popov 2:40
That's right, but that's a different case. The one I'm talking about is where you have a type like string, while the one you have in mind is where you effectively have a type like string or null.
Derick Rethans 2:51
Okay.
Nikita Popov 2:52
In that case, of course, accepting null is perfectly fine.
Derick Rethans 2:56
Even though it might actually end up being different defaults.
Nikita Popov 3:01
Yeah. Nowadays we would prefer to instead, actually specify a default value. Instead of using null, but using mull as a default and then ass