Published 2009-09-21 14:16:30

Just before I saw Brendan's post about PHP4 compatibility in PEAR, I had been getting a few queries about making a couple of my PEAR packages more 'PHP5' compatible or PEAR2 ready.

From my perspective, pretty much all of the packages I maintain (As far as I know) are PHP5 'compatible'. however they may emit E_STRICT errors.

This brings up the interesting question, which I guess all the current maintainers, users and contributors have come across, how much value is added to the existing packages by adding that level of support.

From an 'ideal world' / 'perfect coding' perspective, they would benefit from this changes. but as somebody who earns an income by delivering projects as quickly and efficiently as possible, the return on investment for making those changes is very tiny, if not negative.

Since the packages generally just work, making the changes required, would not really change that 'just work' situation, and as  Jamie Zawinski famously said "How will this software get him laid?"

Two of the biggest changes I'm aware of for this 'PHP5 compatibility' issue are the 'static' method prefix and getting rid of 'var' which completely break PHP4 compatibility (and yes we still maintain PHP4 applications, and clients rarely have budget to make changes like this). Doing these changes would mean that I would have to either freeze or depreciate PHP4 support, or start maintaining dual versions. (Personally I would prefer a hook in the package builder that would do the replacement for me, so I could upload 2 package on each release).

Going forward, PEAR2 is still in a gestation period, (as PHP5.3 and namespaces support has just come out.) Resulting in any code that had  targeted PHP5.3/PEAR2 aging very quickly (eg. requiring changes to handle the final changes to the namespace syntax.). This may start changing soon, however I suspect it would really take some significant effort in time to start creating PEAR2 packages for existing code (which has a rather poor return on investment) . And without a reasonable base number of packages, the attraction of submitting code to PEAR2 is lessened. A classic chicken and egg situation.

At the same time, there is no real alternative to PEAR2, pretty much all other 'framework' solutions have been built around the assumption that you have to accept a majority of the 'framework' to utilize the single packages. Which is even worse that the pains that PEAR(1) imposes on you.

All that said, if you want to send me patches to fix any big PHP5 issues in my packages please don't hesitate, I will try and make the changes.

Mentioned By:
google.com : gg.blogpear.com (99 referals)
phpcamp.net : PHPCamp - Toolbar-PEAR state of play, why move to PEAR2 (97 referals)
google.com : Gg.blogpear (48 referals)
www.planet-php.net : Planet PHP (39 referals)
google.com : Gg Blog Pear (38 referals)
google.com : gg blogpear (32 referals)
google.com : PEAR2 (31 referals)
google.com : http://gg.blogpear.com (24 referals)
google.com : blogpear.com (21 referals)
google.com : http://gg.blogpear.com/vscript (17 referals)
google.com : http://gg.blogpear.com/vscript/ (17 referals)
azby.search.nifty.com : gg.blogpear.com のウェブ検索結果 - AzbyClub : 富士通 (14 referals)
google.com : how to remove gg.blogpear.com (12 referals)
google.com : state of play (12 referals)
google.com : how to remove http://gg.blogpear.com/vscript/ (10 referals)
google.com : ggblogpear.com (9 referals)
google.com : gg.blogpear.com remover (4 referals)
google.com : PEAR PHP5 issue (4 referals)
google.com : gg.blogpear.com/ (3 referals)
google.com : http://gg.blogpear.com/vscript/new (3 referals)

Comments

like a song
...... reminds me words of an irish band's song ... 'does anyone care?'

I agree with you in terms of: 'why would i waste time on rewriting same stuff that still works'. Thats completly valid point.

I also agree that code should be upgraded to make sure it does not cause issues to anyone.

But seriously, does anyone still use PEAR? I think thats the main problem, maybe i just abandoned it because it was not reliable enough it had way too many singletons and it was all about this silly db portability that i have never needed :-)

To clarify, Zend framework does not force you to adopt anything and lets you use very reliable, clean and comprehensive modules. Similarly with easy components.

I have not visited pear for a while and i can see that there is a bit more in web services section now. That is good. But still .... PEAR is just not trustworthy nor interesting enough for some people to bother contributing. Especially when they see php4 code in it ;- )

As long as PEAR is behind people will look away and it will be getting even more behind so maybe after all its worth to port whats worth porting?

Art
#0 - Artur Ejsmont ( Link) on 2009-09-21 17:15:45 Delete Comment
not as hard as it looks
Hi,

There are 2 immediate benefits you would get from removing the E_STRICT errors.

1) every ignored error wastes CPU time, and the performance loss can be significant if there are enough errors (Rasmus gave a talk with some examples of ways to speed up a simple app, and that was one of the fixes)
2) you're more likely to grab maintainers for your code as it looks more current.

Incidentally, there are really only 2 major changes to PEAR code to make it PHP5-ready

static keyword (var is supported without E_STRICT in PHP 5.2+)
use exceptions instead of PEAR_Error

You can also remove all the &new Blah or passing by reference in method signatures.

People have abandoned PEAR because of the PHP5 issue, but also because Zend did a huge aggressive marketing campaign. This was clearly good for Zend, not so clearly good for PHP, as it has drawn developers away from php.net, and PEAR is a great feeder into PHP development (several developers have gone from PEAR straight to php internals development).

Artur's (dramatically misinformed) views of PEAR reflect the mainstream view, which is a shame because there's nothing about PEAR that is "not trustworthy" or "interesting enough." In addition, PEAR has forbade *new* php4 code for over 4 years now. The fact that supporting legacy customers is seen as a liability while requiring innovation of all new packages is a PR failure, not a problem with the underlying code.

PEAR simply lacks a PR budget and a dedicated team paid to develop it.
#1 - Greg Beaver ( Link) on 2009-09-21 23:44:06 Delete Comment
it could actually be true
Im not saying you are wrong at all :- ).... its actually quite possible i may be misinformed about PEAR :-) ... i just did not have good experience back then (about 4 years ago).

Any way, is it possible to switch exceptions globally on pear packages now? so that no other error reporting would be ever used? that would actually be quite cool.

So maybe an agressive information campaign would do a lot of good to PEAR community? maybe preparing some presentations and stats how much is covered in unit tests would be beneficial? Back then i did not like the PEAR's way but maybe its all good now ... would be nice to find out.

You see cool posts on the net about zend/cake etc maybe marketing campaign is what PEAR needs now? : -)

Any way, respect to all contributors :- )
#2 - Artur Ejsmont ( Link) on 2009-09-22 16:50:10 Delete Comment

Add Your Comment