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.
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
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.
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 :- )
