Thoughts on Requiring Patches With PHP RFCs

The impetus for this post comes from two recent great blog posts by Phil Sturgeon:

  1. T_PAAMAYIM_NEKUDOTAYIM v Sanity
  2. Solving the PHP Internals Workflow

I recommend PHP developers read both to get a feel for the current atmosphere and nature of the PHP Internals. All is not well in the land of the core PHP developers. But what I want to focus on with this post is something I consider to be a problem about how the PHP team deals with Request for Comments (RFCs), i.e. change or new feature proposals.

RFCs Are Not Mandatory, But…

PHP Internals says the following as part of their process for submitting RFCs:

  • An implementation is not mandatory while proposing an RFC but it can help persuade people and help fine-tune the design. Note that if you are unable to implement the RFC, and no one else volunteers during the discussion period, then your RFC is unlikely ever to be implemented.

  • Don’t start an implementation too early. Get support for the feature concept from the "internals" mail list before spending time on coding – unless you want a learning experience.

They claim that, when proposing a feature, an implementation of that feature is not mandatory. But my experience lurking on the PHP Internals mailing list has always given me the opposite impression. And that makes the two points above conflicting, particularly the second. They suggest you do not start implementing a new feature too early, but at the same time if you do not come to PHP Internals with a full implementation already in-hand then no one is really going to pay you any attention.

Not only is that frustrating, but I feel like it turns away a lot of would-be great ideas simply because the people proposing them do not have the knowledge to implement the features. I believe someone could write a good RFC for unpacking arguments without requiring the knowledge to implement the feature. Although Nikita Popov, who wrote that RFC, is a great developer who can support his proposals with patches; but I consider him the exception, as most PHP developers do not understand the internal machinery and have no need to learn that.

Except that the culture of the PHP Internals group is one that practically demands working patches before they will even begin to seriously discuss a feature.

A Better Way to do Things

At the risk of sounding arrogant or superior, I feel like the solution to this culture issue is so obvious that I cannot grasp why PHP Internals does not work this way:

  1. User A, someone with experience in PHP, proposes a new feature. It is reasonable (to me) to expect the person to understand PHP well enough to provide realistic use-cases and present some pros and cons of the feature. But there is no assumption that User A can implement said feature into the language.

  2. The developers on the PHP Internals list provide feedback. These people can point out immediate implementation problems that User A may not have thought of, and they can give a reasonable estimate on the effort it would take to implement the feature.

  3. A discussion goes back and forth to iron out details, particularly as they may relate to backwards-compatibility, as that is important for a language as widely-used as PHP.

  4. If the majority of PHP Internals developers and PHP userland developers consider the feature worthwhile then one or more people can begin on the implementation. This does not have to be the personal who originally suggested the feature. If enough people consider it worthwhile then there is a good chance someone will step up to offer help with the implementation.

This is how I watch RFCs unfold in the communities for Python, Lua, Rust, various open-source programs besides programming languages—almost everything except PHP. For example, before implementing excluded tags for the program Busted I first asked for feedback about the idea itself, because why waste my time implementing something only for the lead developers to say, “No we do not want that.”

Doesn’t that sound like a reasonable way to approach things like language changes? I think so. So then why does it feel like PHP Internals disagrees?

I will just end this with a quote of Phil Sturgeon, who bluntly summarizes my feelings about PHP Internals:

Something we HAVE to do is get away from the "if you don’t know C then fuck you" mindset.

Advertisements

One thought on “Thoughts on Requiring Patches With PHP RFCs

Add Your Thoughts

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s