patrikG wrote:
I don't think a replacement for PEAR is necessary - if one remembers where it's coming from, I start to believe that it's actually making headway - and into a good direction.
Replacement - no. Alternatives? Yes, absolutely.
patrikG wrote:
All of us developers arguing about the benefits of our template classes, our great database wrapper or this, that and the other are missing one thing: a real code library. Unless that is there, PHP will always be somewhat of a step-child of "proper" programming languages like Java and C (in all it's variants).
So lets recap - we have a group (PEAR-dev) that says "this is the best, and this is the only way we will do DB access". Then you, as a programmer, look at that method for doing DB access, and see a BETTER version in adodb. So now you have a choice - you can use adodb, or you can use PEAR-db.
Code libraries thrive on competition. PEAR-dev has rejected that fundamental advantage. Thats why Perl does SO well - CPAN isnt controlled by a 'ruling class', its survival of the fittest. Time and again, in CPAN, traditionally well-supported classes are replaced by newer, faster, more functional classes. And then those are replaced by the traditional class, which adds said functionality. The process is both fast and useful.
PEAR has no such competition. Once you are the BLANK pear method, you are in for good, and no other BLANK library can compete.
patrikG wrote:
Let's face it: we (and by that I actually mean I) are a bit like the step-mom always moaning that this and the other is not right, while we are actually not seeing that things are really moving ahead.
Oh things are moving ahead all right, just not in PEAR generally.
Over a year ago, I tried to restructure an app to use PEAR. *HUNDREDS* of admins trying to install my app complained relentlessly about the difficulty of installing PEAR just to get my app working.
Nothing has changed - most webhosting companies don't offer PEAR pre-installed for customers, and as a result, you have to do-it-yourself.
Worse, the license on all PEAR code prevents direct linking with GPL'd code. While the same can be said in reverse (GPL'd code cannot directly link with PHP-licensed code either), for me the issue was stark - the codebase I was working with WAS GPL'd. Once I found out the licenses were incompatible, I had no choice - I couldnt legally use both together.
The movement forward IS happening - there are literally dozens of 'frameworks' of backends for interfacing with everything from databases (adodb), to templating (smarty, etc), and more.
Those frameworks (eclipse, blueshoes, etc) directly provide competition to PEAR. Not only are some of the frameworks smaller, easier to install, and better supported, but they use a license that allows linking to GPL'd code.
I admit to being biased - I am currently working on an extensive 'toolkit' for php developers to utilize ala PEAR.
Competition is key, and PEAR doesnt get that. Never have, never will. Which is why they will lose.