ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back

The value of writing an RFC

So yesterday I spend a few hours writing out an RFC for ifsetor() (note that I put it into the "declined" section). While working through the discussion again, I realized that I had forgotten an important detail in the discussion: Currently we cannot provide a true COALESCE() implementation, which allows for any number of parameters. As such I totally forgot why people felt that the pass by reference hack was considered by these people as a viable approach. I also finally documented in detail why the addition of the shorthand ternary operator "?:" in PHP 5.3 is no replacement either.

I mentioned that I wrote this RFC on IRC. Someone who obviously participated in the original discussion immediately responded with some misconceptions about what ifsetor(), "?:" etc was about. These misconceptions were quite reasonable given the length of the original discussion and how long ago the original debate was. With the RFC it was however easy for him to discover this. I guess this wins over "search the archives".

Comments



Re: The value of writing an RFC

Ah, this is an important way in which Python is already superior to PHP. Not by its technology, but in its development process. It has a complete process by which RFC's get proposed, discussed, and even approved. See http://www.python.org/dev/peps/

By contrast, PHP has a mailing list, with primitive archiving. There is no RFC process. There is no decision process. No history of proposals or decisions is available in a central location.

PHP is okay technology, but it will never be treated as a professional software engineering project while it's run like this.

Re: The value of writing an RFC

Wellllll ... I do not agree. I think processes are great. Actually I tend to be a process junkie. I keep asking for processes in PHP. And I am probably to be faulted for a fair amount if processes or guidelines in PHP. But I also know that one of the key strengths of PHP is that we move very fast when something new comes along. Sometimes we make bad decisions. But none of them have bitten us hard enough yet to have stopped PHP to nowadays being the programming language of choice for web development. Being quicker than the other guys that go through processes has helped us stay ahead of the game more than inconsistency has brought us down.

So actually today I am less concerned about bringing processes to PHP, but bringing transparency into the decision making chaos. This is very similar to processes, but is a slightly different focus that I feel will ensure that we keep most of what makes us strong today, while making it a bit easier to follow what is going on from the outside. In some cases this means writing an RFC when the actual discussion is already over.

Re: The value of writing an RFC

Actually, I think a lot of the decisions made in PHP are horrible and I think that these do actually have an effect on the future of PHP. Now PHP is a bunch of C coders deciding how OO APIs should work and doing a real botch job of it -- whether it's mysqli, PDO, or just the general confusion on strong vs. weak typing in the OO implementation (and already everyone is complaining about the namespace implementation).

PHP has the marketshare for web development, but my guess is that it is not going to hold onto that role forever. Whether it's RoR, Groovy+Grails, or Python + any number of frameworks, there are some serious open-source contenders in this market now that are actually well-designed languages and actually espouse a culture of quality.

PHP is only ahead because of the simplicity of mod_php and the fact that it is entrenched in the shared hosting market -- not because it's a better language. I'd rather it were ahead for its own merits that actually reflected quality. In any event, I would suggest that Python is becoming the industry leader for new, innovative web-driven technologies.