Poorly-named PHP RFCs

One of the things I am better-known for, for better or for worse, is having helped to introduce certain features in PHP. Usually this has been through PHP's Request for Comments process. Since 2013 I have introduced 21 different RFCs, or something near that anyway - the linked list includes an RFC I merely reintroduced, and excludes another. Only 10 of them have succeeded... well, roughly, since scalar types and constant scalar expressions were both eventually gotten in by other people. It's "about 20" that I've introduced and "about 10" that have succeeded, okay? Oh, and some of those were collaborations with other people, so they're not quite mine.

Anyway, the subject of this blog entry is my naming skills, or lack thereof. At least a third of my RFCs have poorly-chosen titles. So, without further ado:

This RFC specified what should happen in some edge cases with the bitwise shift operators and when converting floats to integers. Previously these edge cases were implementation-defined. Defining these might break backwards-compatibility, and I needed to do that for the bigint RFC (see below), so I wrote this RFC to get the changes out of the way.

What's wrong with the name? "Semantics" is rather vague, it simply means "meaning". A better title would have been "Remove integer undefined behaviour".

Like the Integer Semantics RFC, this one was also written to get a backwards-compatibility break needed for bigints out of the way. It made it an error to pass floating-point numbers that were too big to be converted to integers into built-in/extension PHP functions. Previously, PHP would simply silently cut off the most significant digits, which isn't very helpful.

The RFC is poorly-named because the average user may not know what "ZPP" is. ZPP is zend_parse_parameters, an internal C function used by PHP extensions to check and convert the arguments you pass into a function. "Overflow" is a bit vague as well: overflow of what? The number of arguments? A better title might have been "Reject unsafe float arguments for integer parameters".

This RFC added an escape sequence to strings for specifying a Unicode codepoint by number, as an alternative to simply using a Unicode character directly. So, instead of typing "😂" , you could type "\u{1F602}" . It's most useful for things like invisible control characters, which you wouldn't be able to see in the source code otherwise.

The RFC is close to being correctly named, but one word is wrong. It adds an escape sequence, yet the title has the word "syntax". In a programming language, syntax is how tokens fit together to make things like expressions and statements, but escape sequences are within a token, namely a string. The RFC should have been called "Unicode Codepoint Escape Sequence".

This was probably my biggest PHP internals project. Alas, it failed. Anyway, it was an RFC which would make PHP's integer type be arbitrary-precision - that is, you can have an integer of any size, so long as your machine has enough memory; you're not limited to 32 or 64 bits. I liked that because it made integers completely platform-independent: no matter whether you're using a 32-bit, 64-bit, or perhaps a hypothetical 128-bit system, you can use an integer of any size and it will work.

The problem with the name is that PHP already has support for so-called big integers, in the form of the GMP extension. What the RFC would have done is made the basic PHP integer type be arbitrary-precision, rather than you having to use GMP objects instead. In hindsight, it should have been called "Make integer type arbitrary-precision".

A long-standing request in PHP was for an "isset or" function or operator, to reduce the amount of typing needed to check for a variable's existence, and then use that variable if it exists, or use some default value if it doesn't. This RFC finally added one, in the form of the ?? operator: in $a ?? $b , if $a exists then it returns $a , otherwise it returns $b . It follows the same rules as isset() , so if $a is null , then it considers it not to exist.

The RFC was named after the null coalescing operator that some other languages have. But I mis-named the RFC: it should be the null coalescing operator, not coalesce! Worse, it doesn't just check for null in PHP, it also checks if the variable or index exists. It wouldn't be terribly useful if it only did the former, given you could just write a function to do that. As the URL betrays, the RFC was originally called "Implicit isset() in Shorthand Ternary Operator", as at first I tried to make the existing ?: operator do an empty() check instead. It might have been better if I called the RFC "isset() coalescing operator".

(Update: I corrected "coalesce" to "coalescing" in the manual. This doesn't fix the isset() issue, but at least it's grammatically correct.)

This was the RFC that called a vote on whether or not the then-next major version of PHP should be called "PHP 6" or "PHP 7". As you probably know, the result was PHP 7.

"6" and "7" are numbers, not names. And it wasn't the next release that was being named, as that was probably 5.6.x or something. It should have been called "Number of the next major version".

In an incredible instance of irony, the URL of the RFC is /rfc/php6 , despite it being thanks to the RFC that we got PHP 7.

This RFC was my third attempt at adding scalar type declarations to PHP. I'm not going to tell you the story here, see the talk I just linked to instead. It would eventually pass, but not in this form; Anthony Ferrara took it over and created version 5 after I suddenly quit PHP development.

Anyway. "Type hints" are a bad name: a hint is a gentle nudge, not a thing that produces a fatal error when you don't follow it. Python has type hints: its type declarations don't actually do anything, they're only there for static analysis tools. But PHP's type "hints"? They're enforced. Luckily, Anthony was not as stubborn as me. His successor RFC to mine was called "Scalar Type Declarations"… albeit not in the URL.

Conclusion

Think carefully when choosing a name. Double- and triple-check it!