WordPress Weekly episode 6 had some comments about PHP5, that I want to address. It should be noted that they were referring to Matt Mullenweg’s interview at Yahoo!.
To me the argument that Matt was making was that End Users don’t care what language a project is in, as long as they are able to use it. This is true and there is enough proof out there with other consumer products to provide the evidence to support that statement. People only care about one thing, “does it work?” and if it doesn’t then they’ll either find something else that does or if they care enough or have enough patience will try to get it to work (as long as it isn’t the original product that is at fault).
The arguments against Matt’s are developer centric. I will only code in PHP5 for web development, except for a few rare occasions. Those being when I’m writing patches for WordPress, or when I am on a server that only supports PHP4. Both instances are rare in and of themselves, so it isn’t like I’m back in the dark ages. However, PHP4 isn’t that terrible, but in truth PHP4 answered a lot of complaints that a lot of developers had with PHP3. PHP5 offers a lot of enhancements over PHP4, but the amount of people really passionate about them don’t seem to be near the amount of the fans of PHP4 when it was initially released.
The fact that patches have to support PHP4 does limit what I will want to do, because I don’t want to duplicate and back-port something that already exists within PHP5. Likewise, I wouldn’t build a JSON library for converting PHP variables, because that already exists in PECL and is in PHP 5.2.x by default. It would be a waste of time to try to attempt to do so now, since the majority of hosts should be switching to PHP5 anyway.
The second fact is that PHP4 is already in end of life and will only receive security fixes until 8/08/2008 and after that, every bug, whether general or security related is not going to be fixed for any PHP4 version. This means, that WordPress will have to provide any work around for PHP security defects in any affected function. WordPress is also not going to provide any patches for PHP4, so I mean, it isn’t like users of PHP4 will be able to get the fixes from WordPress community. Only user land fixes can be made and sometimes you need to have low level fixes instead. It is very difficult to prevent a stack overflow in userland PHP.
The argument about hosts is that, most shared hosts already support running either PHP4 or PHP5. The statistics reported are just the versions users are running at that time. So even though, the user can easily switch to PHP5, if the user wanted to, but people are making the argument that they don’t even have PHP5, when they do.
I say this with only minor experience with dedicated servers, which I’ve found are extremely difficult to upgrade unless you know someone who knows what they are doing. Site down for 10-30 minutes to upgrade PHP is okay. Site down for 5 hours to 3 days before you completely botched the PHP installation is not cool. If a cluster is not used and the system administration skill level is low, then the odds of keeping up to date are pretty slim.
Doesn’t Have Any Real “Killer Features”
One of the quotes was that, “PHP5 doesn’t have any real killer features that make you need to move away from PHP4…” Okay, this is really based on opinion. I would have to say that either the commenter hasn’t touched PHP5, or just used any one of the great features in any depth. These are just a few of the “killer features” I think PHP5 has and that I think others would enjoy if they switched over to PHP5.
- Database Access Abstraction
To most people who created their own simple database access abstraction, know what a boon and awesome extension PDO is. It is available by default in PHP versions 5.1+. To compare with WordPress, you can replace the entire WPDB class with PDO instance. It would only slight improve the database SQL abstraction, as you would still need to intercept MySQL SQL statements and convert them to the SQL that the database supported can understand.
I’ve built a project, where I was easily able to support both MySQL and SQLite. I could further extend support to any number of other DBMS without having to touch the access layer. This same technique could be used with WordPress to implement an extremely flexible SQL abstraction to where it pulls the SQL from any data source.
Furthermore, WordPress implements a prepare feature that PDO already has, which in PDO is better and faster.
- Filter Extension
Have security issues with filtering input? Not any more. The filter extension allows for handling input with built in techniques or hooking another function in to do the work instead. All of the complaints about WordPress would instantly cease to be relevant.
Now, the Filter extension isn’t a cure-all solution, but by using it throughout you offer a standard interface by either using the filter extension library functions or by building an application sanitizing and validating library around it. The reason you would wrap the filter extension is if it isn’t available (using PHP 5.1 or server admin forgot to install or forgot to enable the filter extension) or if you already have an established library.
WordPress offers a lot for sanitizing and validation, but it can offer more. The Filter extension could be a good solution to solve that problem. I think it is great, but it really isn’t a “killer feature”.
- JSON
JSON, isn’t difficult enough that if you don’t have dynamic data structure changes, that you can write the JSON out for yourself. However, you do have less of a chance of making an error and risk not having your AJAX call work by using the one function it takes to encode a PHP variable to JSON syntax.
- XML Capabilities
Between SimpleXML, DOM, XMLReader, and XMLWriter, I think all of your XML headaches will cease to be. Each of the extensions have their advantages and disadvantages, but it totally wins over regex or DOMXML alone (PHP 4.3+, not including PHP 5.0+ which replaced it with DOM).
- SPL
Iterators, DirectorIterator, and ArrayAccess, might not mean anything to you, but to me, it means that my objects can kick your loser PHP4 objects’ asses. Everytime I’m iterating over a directory, I kiss the ground DirectoryIterator walks on, because it includes everything I’ll ever need in one very simple to use class.
As for Iterators, why return an array from either a method or function, when you can just loop over the object and get back relevant data. WP_Category_Iterator anyone? I’ll tell you right now, if it was available, a lot of developers would be rushing to use PHP5.
- SOAP
I have heard many people shout the praises with having a built-in solution for SOAP. I don’t use it and I suspect others don’t as well. From the criticisms, it isn’t perfect, but for those that it does help, it is that one killer feature.
- Improved Object Oriented Support
If you don’t do OO, then this means nothing to you, but for me, it is the one reason I will only code in PHP5+. The above features are just extra advantages to keep me coming back to PHP5. If you do care about interfaces
- Increase Speed Performance
This is based off a recent benchmark of PHP4 and PHP5 versions. I think for those that speed matters, will enjoy the increase that PHP5 offers. It should be noted that for most tasks it only means a few milliseconds (if even that), but those do eventually add up to a lot.
Of course, for someone else, they will have a different set of features or just might not think anything in PHP5 is that great. In my experience, I don’t know how I lived without these features. I just suggest looking into these above features more before you decide that PHP5 is a non-event.
“…PHP6 won’t be PHP4 compatible…”
That statement is false. The only parts that won’t be compatible are if they applications depends on Register Globals (which shouldn’t anyway since PHP 4.2), safe mode, or magic quotes. Those that don’t depend on those three should have only a few minor issues depending on whether they are using a function that has been deprecated since PHP4 or PHP3 (I’m referring to the E_DEPRECATED error level that might be part of PHP 5.3 and PHP6).
There might be others, but until PHP6 is released, I think people should hold off on statements, because it is like saying PHP 5.3 is going to have namespaces. Right at this moment it does, but that can change in the future (or might have already changed since I last looked at the debate). It can be pulled just like it was for PHP 5.0. That only sure thing about PHP 6.0, is that it is going to have Unicode, which shouldn’t affect the majority of string functions out there.
Until PHP 6 is released, I think the only ones that know now verses those that will know then when everyone will know, are the ones that are developing PHP or watching the Internals.
Possibly Related Posts:
- Bullet: E-Book Library Management and Content Server
- Using ZendFramework 2 beta1 For Directory Project
- The Way of Kings and Cosmere Theory
- “In Time” Movie Premise Flawed
- Completing HTTP Library For PHP
Jacob, I’m afraid I’m the guilty party from the podcast.
The killer features thing is open to debate I guess, but the PHP 6 compatibility isn’t. I was just wrong.
I was convinced that PHP 6 would not support the PHP 4 object constructor, but I can’t find any reason why I was convinced of that now, and believe me I have looked.
After correcting the places I have made that claim I will keep my mouth shut about it as you suggest.
Don’t forget the DateTime object. Proper, modern timezone handling complete with daylight savings support. That’s hot.
Even if the API for it isn’t perfect (DateTime should be a value object, not a mutable object), the underlying functionality lets you do things with dates that were almost impossible before.
@Larry
Totally. I’ve had a lot of fun with the DateTime and time zones. So much easier. Just set the timezone and ask for the time. No trying to get the GMT and doing calculations and hoping that the user doesn’t want anything to happen at midnight or have to account for leap years.
I also forgot file_put_contents(), which is sweet, but I don’t use it as much as its sister file_get_contents().
@Andrew
As someone who is wrong, a lot, and I mean a lot. I think the best practice is to admit it to the person who you argued with and then try not to make the same mistake. Although, a better practice would be to do the research first, but I’ve assumed that if I don’t post sources that readers will take my post with a grain of salt. I make the mistake of thinking that other developers aren’t like me.
It is what I try to do, after having been proved wrong on mailing lists and on this blog. As for PHP6, I honestly have been out of the loop so long, I have no idea, since what I’ve read over a year ago I’ve forgotten a lot of it now anyway. I believe that the PHP6 TODO wiki has a lot of good information on what has been done already and what will be done in the future (however, I have no idea what the link is).
However, after having listened to the podcast three times, I think a lot of what has been said is truth, even if a lot of it was opinion. Finding what drives a person to PHP5 is a personal journey or at least it was before the end of life of PHP4.
I think the driving force for those who want to make the jump to PHP6 is Unicode, because they’ve had to angst over Multibyte and supporting localization and internationalization of their projects. However, as someone who has had to work with XML, I found DOM (and DOMXML for PHP 4.3+) to be just awesome).
In my perspective, I can name at least 5 things that PHP5 does for me. I do understand from reading the comments of others that transitioned to PHP5, that everything I think is great and awesome isn’t exactly all that great to another person. Someone that uses ADODB probably doesn’t think PDO is all that great, because PDO doesn’t offer anything for them.
I think read-only view of the PHP Internals mailing list is a good thing, because there are a lot of really intelligent people on the list and you can learn a lot of where PHP is going in the future. However, if you don’t know C/C++, then it is probably best to say out of the debate. I do, because I’ll be wrong a lot and I can’t provide any patches.
As for keeping my mouth shut, I’m also taking my own advice and removed some comments I made that were speculation and probably wrong. Even though this post is mainly an opinionated post, I think adding content that has a high probably of being inaccurate shouldn’t be propagated. With truthfully, there are other portions of that section that need to be removed as they also have a high probability of being wrong.
I do want to also say, Andrew, that I’m not trying to call you out on anything, but if one person feels this way about PHP5, then I have to assume that others feel the same way. If the question is, “What does PHP5 offer me?” then I’m giving the answer, but it is in no way definitive.
I love PHP5 more than PHP4 and I wish everyone felt the same way.
I like PHP5 over PHP4 because:
+ OO model is rewritten. This is the first time that I can say that PHP support OOP strongly and correctly.
+ XML/DOM/SOAP/JSON support is really good and industry standard compliant. PHP is totally exposed itself to the world of webservices and business applications.
+ Vastly improved database support: PDO, new mysqli, new mysqld and lot of improvements in PostgreSQL, SQLite
+ Security enhancements: Filter extension and many security bug fixes
+ Improved date and time support: DateTime class and its relatives are great.
+ SPL: a huge add-on to PHP
+ Enhanced error handling model: Fatal error now leads to 500 server error header sent instead of a blank page. Exception support come into play.
+ Memory management model takes swing.
+ Text processing gets a lot of improvements with new array-related function, Tidy extension, file-related functions
The biggest part to PHP5 success should be PHP5 frameworks: Zend Framework, SolarPHP, Symfony
I dont expect much in PHP6 because PHP6 = PHP5.3 + Unicode
@pcdinh
I wouldn’t count PHP6 out yet. I think it is great they are backporting a lot of PHP 6 features. This should only get developers ready for PHP 6 when it comes out. Instead of saying, this web package only supports PHP 6 to take advantage of namespaces. You will hopefully be able to take advantage of namespaces in PHP 5.3 and extend it to when PHP 6 comes out.
I think also, it will help work out bugs and issues with some of the more experimental features, like namespaces. The problem is that I would rather not have a repeat of PHP 5.0 with namespaces, where they add it, only to pull it away, because it was imperfect. My hope is that they will incremental improve it, so that by the time PHP 6 comes out, the implementation will be perfect, much like OO support was in PHP4, then improved in PHP5. It was imperfect, but it was better than not having OO support.
There seem to be only a few that share my opinion. However, the last time I looked at the namespace debate it appears that the implementation in PHP 5.3 and eventually PHP 6 will be totally awesome.
However, I don’t think this takes away from PHP6 in anyway. A lot of people will be looking for native Unicode support and you can’t discount the other additions in SPL (unless they backport those also).
Who knows, PDO2 might be part of PHP6 or it might be backported to PHP 5.4. I do wonder if they will continue backporting PHP 6 features when it is released, but I do doubt it, so it is better that they are doing so.
I completely look forward to PHP 5.3 (even if it doesn’t have namespaces in the final version, but I’m still crossing my fingers). I think the biggest problem when PHP 5.3 comes out is whether developers should fully support it. It is unlikely that all of the PHP 5.2 shared hosts are going to jump aboard PHP 5.3 quickly, because of standard hosting practices.
I’m kind of glad that some applications havn’t made the transition to PHP5 yet, because the argument can then be made to jump immediately to PHP 5.3 instead (that is most likely a pipe dream). So we’ll be left with a major transition in a x.3 release when a lot of applications are stuck supporting a x.2 branch. At least, until the requirements are again raised to support that PHP version.
I just wish Tidy and FileInfo extensions were installed and enabled by default on most PHP installations. I love HTML Purifier, I really do, but sometimes I do need to have the information in HEAD for when I use the library as a Tidy alternative.
I like the backport of features from php6 to 5.3, But thats mostly due to PHP6 taking quite some time to release. Unicode is great for PHP6, but is it enough to get people to migrate to php6?
The todo wiki is currently located at:
http://wiki.pooteeweet.org/PHPTODO/
I am hoping that it will seen be on wiki.php.net.
Thanks Jacob.
I am in two minds about whether WordPress / Automattic should take the chance of alienating a significant number of users for the good of the remainder and the future of the product so on the podcast I took the view I thought would be most reasonable.
Deciding whether to develop a new product in 4 or 5 is a no-brainer, but switching a mature product with millions of users, that is a hard decision.
I’m glad it isn’t my decision but if it was I would opt for PHP 5 and tell people to switch hosts if they won’t make PHP 5 available.
I do love PHP5 but developing for WordPress means I can’t use those features except when I want to force the issue, or when I develop only for my own use. I’ve used simpleXML, and object iterators and I like them a lot.
Yes. Well, only for those I’ve talked to and for myself. People were speaking of the graces of PHP6 long before the features were backported and long before namespaces was a sure thing. I think for some people the sediment was always, “I’m just going to switch to PHP6, it is PHP5+Unicode.” But in a good way.
Now it is used almost as an insult, “Pfft, why should I switch, it is PHP5+Unicode.” Which says good things about PHP5.3, but if i10n isn’t important than I can see why they would feel that way.
I doubt I will have to write a similar post for PHP6, but there might be more people out there that will make the jump straight to PHP6.
Well, have to find out when PHP6 is released and see what the adoption rate is or poll 1000 to 10000 developers and see what their mindset is.
To the new/improved features in PHP5, I would add:
# class autoloading
# type hinting
# DateTime class
# namespaces
Any developer sooner or later will switch from PHP5 to PHP6, from PHP6 to PHP7, etc, etc