Thoughts on the PHP Named Parameters RFC

Honestly I do not write too much PHP software these days. But I remain interested in the language and so I like to keep up with its development. Being the maintainer of PHP Mode gives me more incentive to stay informed.

Today I want to share my thoughts about Nikita Popov’s RFC for named parameters.

Accept the Feature Already

The RFC shines light on a problem that I have with the culture of the core PHP developers. I do not want this article to sound like a personal attack on anyone; I respect the core PHP team. But I take issue with how they handle proposals for certain features.

Popov’s RFC for named parameters does a great job of demonstrating why the feature would benefit PHP. He even shows why it is (in my opinion) better than the somewhat-related RFC for skipping optional parameters. But Nikita Popov is not proposing this idea for the first time. People have suggested it as early as 2005, where the PHP developers gave this response:

We don’t see the real need for named parameters, as they seem to violate PHP’s KISS principle. It also makes for messier code.

First of all, I find the argument about ‘messier code’ to be ridiculous. They help the readability of languages like Python and Common Lisp. Could named parameters be abused to write messier code? Yes, they could. But I think it is a very weak argument against any feature to say that bad programmers could use that feature badly. Bad programmers can write messy code with classes, so should we also ban OOP? The idea is ludicrous.

Second, I find it disingenuous for the core PHP team to claim that PHP development follows the KISS principle. If PHP stuck to that concept then we would not have a bunch of string functions that begin with str_ and a bunch which lack the underscore, we would have a consistent order of $needle and $haystack parameters across all relevant functions, we would not be able to increment NULL (seriously—what is the purpose of that), et cetera.

I also find it odd that the PHP team readily accepts features like traits, which are honestly useful, but bluntly rejects named parameters, a feature that people have lobbied for much more than they ever did for traits.

The PHP developers understandably want to avoid breaking backwards-compatibility. However, Popov’s RFC would not do so. Admittedly it introduces some issues, e.g. I am not personally crazy about how it affects func_get_args() and related functions. But I believe the community could iron out these issues if the feature was not out-right rejected.

The RFC, to me, demonstrates that the core PHP team is out of touch with the majority of PHP developers. They do not seem to have an accurate grasp on what features developers genuinely want and which would help improve their work. I hope this will change in the future. But considering the history of PHP I honestly and unfortunately have no reason to believe it will.


Add Your Thoughts

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s