This post originated from an RSS feed registered with PHP Buzz
by Alan Knowles.
Original Post: PEAR state of play, why move to PEAR2
Feed Title: Smoking toooo much PHP
Feed URL: http://www.akbkhome.com/blog.php/RSS.xml
Feed Description: More than just a blog :)
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.
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.
Previous Topic
