Ah, hindsight: like foresight, but without a future! I hate articles that being with “in hindsight...” on principle, but it's sometimes useful to take a look at the past to map out a better future.
Lately, PHP can't seem to catch a break. People seem to enjoy complaining about how all the cool kids have moved on to Rails, how the PHP development process is controlled by a small group of elitists who completely disregard the community's needs, or by corporations who care only about their financial well being, or little green men intent on weakening the human race in preparation for a full-scale invasion that will, undoubtedly, start any day now.
And let's not forget everyone's favorite complaint: that it's impossible to write secure/scalable/stable/working/enterprise/insert-your-buzzword-of-choice code in PHP.
These topics have been beaten to death, and will likely continue to be beaten well after their bones have turned to dust. However, I have never had the opportunity to explore some aspects of PHP that obviously are mistakes—not just to understand their origin, but to analyze their impact on PHP and the way they have been dealt with.
Naturally, I don't doubt that, if someone actually does read this column by mistake, there will be sharp differences about what the biggest mistakes are—and, while I could hope that everyone will agree with my conclusions here, I'm not really holding my breath—I will, instead, wish for a healthy number of thoughts and comments!
I thought I'd start with one item that is sure to make my four readers think that the only goal of this month's column is to troll. Nothing could be further from the truth: OOP support in PHP 4 was a mistake, because it wasn't well thought out at all (as, in fact, several core developers have mentioned more than once).
What's interesting about OOP is that it had the double effect of attracting many developers to PHP from other programming languages where objects were readily available but the platform lacked in other areas (ASP being a prime example), while at the same time causing an inordinate amount of headaches and backlash because of its poor implementation. This is the classic case of a feature being implemented in an experimental way only to take on a life of its own and gain immense popularity—only to cause great resentment when people who didn't bother to read the fine print ended up banging their heads against OOP's limitations.
Raise your hand if you've ever introduced a bug in your code because the parameter order of a function wasn't what you were expecting. For me personally, this is the single worst annoyance with PHP—it's the one thing that I can't learn how to work around. If it weren't for the autocompletion feature of my IDE, I would have to constantly look functions up in the manual.
This problem is clearly the result of PHP's haphazard growth—in itself, not necessarily a bad thing, as the platform grows only where and when it needs to. It is made particularly puzzling by the fact that fixing it—at least on a go-forward basis—would be relatively easy: all that is needed is a simple set of conventions for every developer to follow, much like the ones that already exist to guide coding standards.
