Shaun wrote at 9/18/2009 1:59 am:I know what you mean. I primarily use CakePHP and I get tired of seeing ‘var $foo’ whenever I bake a new application. I change it to ‘public $foo’ out of spite.
| « Peer Review: You Have Not Because You Ask Not (Requests & Responses) | Custom Apps: Some Strategies For Easy Configuration Files » |
Recently, I’ve been getting more and more into community-supplied code, since it’s generally been getting better. Namely, I’ve been exploring the PEAR offerings, and seeing what pieces I can integrate into my personal framework for development. One of these packages is the package called Log, which allows for easy logging of application events.
So imagine my surprise and sadness to learn that the package still supports PHP 4.
The truth is that there are lots and lots of hosts that are still on PHP 4. There are still lots and lots of lines of PHP code that make use of PHP4-level features (see WordPress and Drupal for examples). My complaint is that PHP 4 has been officially unsupported for the last year now, and PHP 5 has been out for over five years. Five years! That’s a long time to wait to take advantage of new features in the language.
Sadly, developing for PHP 4 backwards compatibility is something that companies and individuals are still doing. WordPress released a new Widget API in version 2.8 that relies on the old-style PHP 4 constructor. Apparently, for WordPress and many other developers, wide adoption is more important than language improvements.
In the case of Log, supporting PHP 4 is a reality and a requirement imposed by PEAR. I certainly do not discount the efforts of package maintainers like Jon Parise, Jan Schneider and Chuck Hagenuch, who are bound by PEAR’s rules that prohibit the breaking of backwards compatibility. These individuals are working hard to support a package that is used by hundreds of developers, and is depended on for the proper functioning of 21 individual PEAR packages. I’ve been in the process of working through a PHP 5 version of the Log package, both for my own use and perhaps contribution to the community, because I think that having the ability to use statics, abstracts, interfaces and typehinting are important enough to merit the work.
Still, I look forward to the day when PHP 4 finally does go away forever, leaving us with a much better code base and happier developers.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 9/18/2009 at 1:00 am
I know what you mean. I primarily use CakePHP and I get tired of seeing ‘var $foo’ whenever I bake a new application. I change it to ‘public $foo’ out of spite.
Sudheer (@bngsudheer) wrote at 9/18/2009 2:31 am:
I am looking forward for the day when all PEAR packages deprecate PHP 4 support.
e.s.t wrote at 9/18/2009 4:14 am:
So say we all!
Zilvinas wrote at 9/18/2009 4:51 am:
I believe it will be 10 more years before support for it will die and there will still be companies that will hire you to support that code :]
Peter Hopfgartner wrote at 9/18/2009 5:47 am:
I do not have any numbers, but my subjective impression is that PEAR has lost a good part of it’s importance due to a lack of innovation.
We moved mostly away from PEAR to a framework that is completely based on PHP 5.2. So we can rely on correct exception handling, SPL, PDO, decent OO and all the other nice stuff that this millennium brought to PHP.
Unfortunately due to this lack of innovation PEAR has lost completely the technical leadership and too many frameworks appeared, none of them truly authoritative.
Brandon Savage (@brandonsavage) wrote at 9/18/2009 7:34 am:
I don’t think that PEAR is going to vanish any time soon. In fact, that wasn’t the point of my article. I understand why Log is still PHP 4 – PEAR doesn’t want to raise the middle finger to anyone who is relying on that code for legacy applications. Some people think keeping backwards compatibility is a bad idea, but I see their reasoning, and I don’t think they’re unreasonable.
It’s worth noting that all new PEAR packages must support PHP 5, and that the PEAR2 standard will require PHP 5.3.
Shaun (@farrelley) wrote at 9/18/2009 9:23 am:
I agree with the PHP 4 Support stuff. But PHP end of life has only been 1 yr. I know it sounds bad but, if hosts stop supporting php4 there would be a lot of unhappy customers. I think it will be about 4 or 5 more yrs before hosts drop php4 as any option. On the other hand, I think a lot of open source code is either being converted or new code is all php5. Log Framework in Pear has been around since 2003! unless PEAR requires PHP5 i don’t think Log will change!
Log can’t change due to the backwards compatibility rules. But PHP 5 has been out now for about five years. Adoption of a new version of PHP will take ten years? I think that’s crappy and foolish, especially since you consider that PHP 5 was released in 2004, as was Gmail, which has a wide adoption. Not moving to the newest version of PHP is laziness on the part of web hosts. Log continues to support PHP 4 because people continue to use it; if everyone moved to PHP 5, I’m sure Log would be ported, as would much of PEAR.
jakyra wrote at 9/18/2009 10:16 am:
I don’t use PEAR because I like to have my error settings on E_STRICT and throw exceptions rather than notices. I have to downgrade my system to use PEAR. No thank you.
Paul (@paulyg76) wrote at 9/18/2009 10:25 am:
“laziness or web hosts” is right. I have found that shared hosts still running PHP4 do have boxes running PHP5 and will move you if you request. But you have to request. In one instance the did it willingly, in another instance I had to threaten to take my business elsewhere. But unless users make noise they won’t get the grease. And I’d venture to guess most WordPress users don’t care what PHP version they are on.
If anyone is thinking of contributing to PEAR I would suggest taking your favorite package and rewriting it for PEAR2 w/ PHP5 features. There is a list of packages that need converting on the PHP Wiki: http://wiki.php.net/pear/packages/migration. Also there were a few packages that were made PHP5 only. HTML_QuickForm2 comes to mind.
Matthew Weier O'Phinney (@mwop) wrote at 9/18/2009 12:18 pm:
Technically, if the authors of the Log package wanted to, they could create a Log2 package that’s PHP 5 only — that’s the current solution for introducing BC breaks. The problem is there’s likely not much incentive for them to do so.
BTW, if you’re looking for a PHP 5 specific log component, Zend_Log is a really nice one with support for a variety of backends — including FireBug, Mail, and more. Not that I’m biased or anything. ;)
Matthew, I’ve looked at most of the Zend components and even adapted some of them. The problem that comes with some of the is their integration into the larger Zend Framework – that is, it’s difficult to decouple some of the components. That’s certainly not true of all of them (there’s supposedly a list of those that stand alone, but I can’t seem to find it), and I don’t know that it’s true of Zend_Log. I was planning to look into it this weekend.
I think that there’s incentive but perhaps not time. If I was writing Log, which is stable, I’d be wary of porting it over and then having a branch that I’d have to support independent of the trunk. Especially since all of the problems are E_STRICT-related…
ezComponents has a fine Log (http://www.ezcomponents.org/docs/tutorials/EventLog). And it can be used without too many dependencies.
Daniel Londero (@dlondero) wrote at 9/18/2009 5:24 pm:
Looking only at projects I think that a lot of developers will/must maintain PHP4 code because there are no money from the client to jump on a brand new version of the app with PHP5.
Fortunately new projects from scratch can start with PHP5 and with all advantages (for developers and committers).
Larry Garfield (@Crell) wrote at 9/19/2009 5:00 pm:
For the record, Drupal was a founding member of the GoPHP5 project. Drupal 6 was the last version that supports PHP 4. Drupal 7 has had a very long development cycle, but is now in partial code freeze and we anticipate release probably sometime in quarter 1 2010. It is very much PHP 5-only, and makes use of PDO for the database layer, exceptions, SPL, PHP 5-only functions, and all that jazz. Already in Drupal 6 there are a number of contrib modules that are PHP 5-only, something that is actively supported by Drupal’s module system.
WordPress was just about the only major project that didn’t sign on to GoPHP5. Of course, we’ve not been auditing the code of every project so we can’t say that all are holding to their pledge, but enough are that really, any project that rejects PHP 5-dependent code I would define as a dying project, and one to jump ship from immediately.
Larry, I’m glad to hear Drupal is moving towards PHP 5 and I’m excited about Drupal 7. I know that WordPress is starting to move that direction, and will be PHP 5-only as of WordPress 3.0.
Jeff Dickey (@jeff_dickey) wrote at 10/13/2009 3:56 am:
Brandon, PHP 4 is the Visual Basic 6 of the Web. People who know better avoid it like the plague, but too many dabblers (and projects oriented to them) want to play with PHP because they “don’t have to really learn how to program,” as one twit put it.
I expect PHP 4 to finally recede from everybody’s nightmares sometime in the PHP 9-10 timeframe. That’s one of the reasons I’m really, REALLY questioning whether PHP is the best Web dev platform going forward. At best, I sense a huge fork coming.
| « Peer Review: You Have Not Because You Ask Not (Requests & Responses) | Custom Apps: Some Strategies For Easy Configuration Files » |