PHP Internals News: Episode 99: Allow Null and False as Standalone Types – Derick Rethans

PHP Internals News: Episode 99: Allow Null and False as Standalone Types

In this episode of “PHP Internals News” I talk with George Peter Banyard (Website, Twitter, GitHub, GitLab) about the “Allow Null and False as Standalone Types” RFC that he has proposed.

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:15

Hi, I’m Derick. Welcome to PHP internals news, a podcast dedicated to explain the latest developments in the PHP language. This is episode 99. Today I’m talking with George Peter Banyard, about the Allow null and false at standalone types RFC that he’s proposing. Hello, George Peter, would you please introduce yourself?

George Peter Banyard 0:36

Hello, my name is George Peter Banyard. I work on the PHP language, and I’m an Imperial student in maths in my free time.

Derick Rethans 0:44

Are you’re trying to say you’re a student in your free time or contribute to PHP in your free time?

George Peter Banyard 0:49

I feel like at this time, it’s like, both are true at the same time.

Derick Rethans 0:53

Let’s hop into this RFC. It is titled allow null and false as standalone types. What is the problem that it is trying to solve?

George Peter Banyard 1:02

This is the second iteration of this RFC. So the first one was to just allow null initially, and null is the unit type In type theory parlance of PHP, ie the type which only has one value. So null is a type and a value. And the main issue is that when for leads more with like inhabitants, and like the Liskov substitution principle. If you have like a method, like the parent method, which can be told like either null or an object, and your implementation in a child class always returns null, for various reasons, maybe because it doesn’t support this feature, or whatever is out, or… If your child method only returns null, currently, you can’t document, that you can’t type this properly, you can document it in a doc comment or something like that. But due to how PHP type handling works, you need to specify at least like another type with null in the union. Basically resort to always saying like mimicking the parent signature, when you could be more specific. This was the main use case I initially went into.

Derick Rethans 2:08

If I understand correctly, you can’t just have an inherited method that has hinted as to just return null?

George Peter Banyard 2:14

Exactly. If you always return null, maybe because you always work or something like that, then you must still declare the return type as like null or exception, which is not a concrete because you say what, like why never fail. And like static analysers, if they can figure it out that you’re using a child class, they can’t maybe like do some assumptions or work further down that like what you’re doing is redundant or things like that. So that’s one of the main reasons I initially went with it. And I didn’t add false initially, because it was like, well, false, it’s not really a type properly. It’s, it’s what’s called a value type. False is one value from the Boolean type. And I was like, Well, okay, we’re just going to limit it to like, being the type theory purist, limited to proper types, where null is a proper type, although it’s a bit sometimes misunderstood, I feel in the PHP community at large. And then people were like, well, if we add nu

Truncated by Planet PHP, read more at the original (another 13058 bytes)

Xdebug Update: February 2022 – Derick Rethans

Xdebug Update: February 2022

In this monthly update I explain what happened with Xdebug development in this past month. These are normally published on the first Tuesday after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 46% towards my $2,500 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In February, I spend 26 hours on Xdebug, with 24 hours funded.

Releases and Development

As first task in February I released Xdebug 3.1.3 which addressed a bug with the debugging protocol’s eval command and exceptions, an issue with the debugger generating invalid XML, and a memory leak and performance issue with tracing.

Since then I have worked on triaging and fixing a few more issues. These have currently not been merged due to changes in GitHub Action’s Windows support. I expect that to be resolved by the time you read this.

Fixes include a crash while using closures and static properties, something that Symfony Cache seems to use a lot, some memory leaks, and an issue with the legacy XDEBUG_SESSION_START trigger. I expect Xdebug 3.1.4 to be released imminently.

Priorities

In the previous update I wrote about what I had in mind for this coming year. From feedback to this communique, and a highly scientific Twitter poll I’ve decided to prioritise the following items:

  1. Creating an Xdebug Course: explaining in great detail how Xdebug works, how you use it, how you can get the most out of it, and many scenarios on how to set-up debugging in different environments. This needs to go beyond referential documentation pages, and will hence become a combined set of videos and tutorials, with examples and work-along exercises.

  2. Xdebug Recorder and Player: A new feature in Xdebug which would allow for a full request to be stored in a file, including every intermediate state. Combined with a player, which would allow for replaying the request and interrogating every variable at every point during the execution of said script, through the debugging protocol and interacting with your IDE. The recorded files would be self contained, without needing access to the (original) source code. Besides “step over” it would also have a “step back”, and perhaps even a slider to slide back and forwards through time.

I have started making an outline for the Course, and a prototype for the Recorder and Player.

Let me know if you have ideas about which specific topics the Course should offer.

Xdebug Videos

I have published one more video on how to use Xdebug on my YouTube channel.

Truncated by Planet PHP, read more at the original (another 843 bytes)

Log4j, Faker and Black Swan Events – Evert Pot

In December log4j, a library that’s used by a massive amount of projects had
a major vulnerability, and in January the author of ‘Faker’ and ‘Color’
went nuclear, released a intentionally buggy version that broke a lot of
projects (temporarily).

A lot has been said about both of these, but I wanted to add my own (very late)
take to this.

I think the general theme of what people are writing about this is is: this
is a major problem with open source. Critical projects aren’t getting enough
funding.

In the case of Faker.js/Color.js, a lot of people in the Node.js community
suggested to no longer specify ‘version ranges’ for dependencies but lock
everything to a specific version in package.json.

I however found myself disagreeing with both of those conclusions.

For both of these major issues, I looked at the events
unfolding and I have a hard time reaching the conclusion that there’s a big
problem that needs to be solved. It was quite the opposite actually.

It’s hard to find exact statistics, but the sources I could find suggests
that there’s at least 100,000s of open source developer as many open source
packages. If we have couple of major issues like Log4j and Faker.js every
year, that feels like a number that’s not really worth optimizing for.

Proprietary or well-funded software can also have major security bugs,
and in each of these cases workarounds popped up fast and the issues were
fully resolved within 2 weeks for most users.

Yes, the issues themselves were problematic and I have sympathy for the
developers involved and how they were treated, but the conclusion I got
from these events is that things are actually pretty robust and correct
themselves in the face of major issues.

A counter example of the open source world, a report recently came out that
Linux developers generally fix bugs faster compared to Apple, Google
or Microsoft by a wide margin.

I don’t want to deny that that open source needs more funding. It’s
a complex issue that I don’t know enough about, but If there are indeed
major structural issues related to how open source is developed, we should
look at widespread problems and not ‘black swan events’.

I’ve often seen organizations trying to find and fix root causes for any
issue that pops up, but all these process changes can lead to a situation
where it’s hard to get anything done. An important part of any post-mortem
should be ‘how can we prevent this in the future’, but also ‘is this issue
common enough to prevent it from happening again’.

PHP Internals News: Episode 98: Deprecating utf8_encode and utf8_decode – Derick Rethans

PHP Internals News: Episode 98: Deprecating utf8_encode and utf8_decode

In this episode of “PHP Internals News” I chat with Rowan Tommins (GitHub, Website, Twitter) about the “Deprecate and Remove utf8_encode and utf8_decode” 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:14

Hi, I’m Derick. Welcome to PHP Internals News, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 98. Today I’m talking with Rowan Tommins about the “Deprecate and remove UTF8_encode and UTF8_decode” RFC that he’s proposing. Hi, Rowan, would you please introduce yourself?

Rowan Tommins 0:38

Hi, I’m Rowan Tommins. I’m a PHP software architect by day and try and contribute back to the community and have been hanging around in the internals mailing list for about 10 years and contributed to make the language better, where I can.

Derick Rethans 0:57

Excellent. Yeah, that’s how I started out as well, many, many more years before that, to be honest. This RFC, what problem is this trying to solve?

Rowan Tommins 1:08

PHP has these two functions, utf8_encode and utf8_decode, which, in themselves, they’re not broken. They do what they are designed to do. But they are very frequently misunderstood. Mostly because of their name. And because Character Encodings in general, are not very well understood. People use them wrong, and end up getting in all sorts of pickles that are worse than if the functions weren’t there in first place.

Derick Rethans 1:37

What are you proposing with the RFC then?

Rowan Tommins 1:39

Fundamentally, I’m proposing to remove the functions. As of PHP 8.2, there will be a deprecation notice whenever you use them, and then in 9.0, they would be gone forever, and you wouldn’t be able to use them by mistake, because they just wouldn’t be there.

Derick Rethans 1:56

I reckon there’s going to be a way to actually do what people originally intended to do with it at some point, right?

Rowan Tommins 2:02

So yeah, there are alternatives to these functions, which are much clearer in what you’re doing, and much more flexible in what you can do with them so that they cover the cases that these functions sound like they’re going to do, but don’t actually do when you understand what they’re really doing.

Derick Rethans 2:20

I think we’ll get back to that a little bit later on. You’re wanting to deprecate these functions. But what do these functions actually do?

Rowan Tommins 2:27

What they actually do is convert between a character encoding called Latin-1, ISO 8859-1, and UTF-8. So utf8_encode converts from Latin-1 into UTF-8, utf8_decode does the opposite. And that’s all they do. Their names make it sound like they’re some kind of fix all the UTF 8 things in my text. But they are actually just these one very specific conversion, which is occasionally useful, but not clear from their names.

Derick Rethans 3:01

It’s certainly how I have seen it used in the past, where people just throw everything and the kitchen sink at it, and expecting it to be valid UTF 8, and then at the end, decode. I mean, the decoding was not even part much of this, right? It’s just throw ev

Truncated by Planet PHP, read more at the original (another 23825 bytes)