I recently saw yet another discussion online about PHP’s infamous naming convention exceptions and needle/haystack rotations. All the typical vitriol was there from the PHP haters, but I was very happy to see several new programmers add to the conversation or ask for clarifications and receive very supportive and educational responses from the thread. PHP is nothing if not consistent in its status as a recipient of the internet’s hatred. However, I am forever proud of our community’s ability to ignore the hate and still welcome and encourage newcomers.
But do the haters have a point about our inconsistencies?
I mean, they are not wrong that sometimes it is “needle/haystack” and other times it is “haystack/needle.” Sometimes it’s “in_,” and other times it’s “contains_.” I freely admit to needing to check the docs or use tooltips in an IDE when using functions I don’t use very often because I can’t remember which way it will go.
**Is it phpinfo() or php_info()? vardump() or var_dump()? Has anyone thought of just fixing this? ****
Most definitely. In fact, PHP RFC Consistent Function Names (consistent_function_names) will turn seven years old next month. This RFC proposes renaming any inconsistent functions and keeping their old names as aliases. No backward compatibility issues. Everyone can keep using whichever version they want to. It seems like a proposal that would satisfy the people who want everything renamed and those who do not want the names changed. So what’s its status? You guessed it. After all these years, it is still listed as “Under Discussion.”
Why is it so difficult to make a decision on something that garners PHP so much hate? Especially when there is seemingly a perfect solution to make everyone happy? **
Well, that’s the thing. Despite how it looks on the surface, renaming and aliasing is not a perfect solution. PHP has had these function names for so long they are expected to be a part of the code.
Does this mean we can’t change them because we don’t like change?
Absolutely not. It means is that other libraries and codebases have been working around those function names for well over a decade or two. For many codebases, it means they have wrapper functions using the proposed standardized versions of the function names because they prefer standardization. Or they have built custom functions and used the proposed standardized function names because those weren’t reserved. Standardizing the function names and order of variables means adding a lot of new reserved function names that could break a lot of code.
Don’t we add new functions to PHP all the time, which does the same thing?
True, but in those cases, the BC breaks come with the benefit of new functionality. In this case, we would be introducing a lot of BC breaks with no new functionality.
Isn’t a better dev experience worth it?
Maybe. Consider, though, the huge list of amazing new features, security patches, bug fixes, and everything else on the horizon for PHP. Do we really want to spend our limited core developer time on something that only improves the dev experience for some devs. It is really hard to justify this when it means losing time to work on a new feature or fix that could improve things for all devs. When dealing with limited volunteer resources, there are lots of tough decisions to make.
But what about all the haters who say PHP is ugly because of this?
As the saying goes, haters gonna hate. In PHP’s decades of life, there have always been haters. No matter what we do, there will still be haters. Look at the amazing modernization strides that PHP has made in the last five years! The perception that PHP is old, clunky, and ugly is not based on legitimate facts but rather long-held biases. Those biases aren’t going to go away even if we made naming conventions perfect, which I’d venture to say that no language could truly achieve given the ever-changing nature of programming.
So is this a dead issue?
Definitely not! There is merit to the concern and potential in the suggested solution. It just isn’t the right time for this kind of a change, and that’s why as we draw near to this RFC’s 7th birthday, this continues to be “Under Discussion.”
Related Reading
– PHP RFC: Consistent Function Names https://wiki.php.net/rfc/consistent_function_names
Originally published in “Parallelize Your Code”, the February 2022 issue of php[architect] magazine.