Page 1 of 1
Is PEAR worth using?
Posted: Sun Mar 18, 2007 8:37 am
by seodevhead
For the past 2 years I've read and heard a lot about PEAR and it's many libraries. I've heard both the good and bad. But I am not sure if it is even worth my time to learn and implement on my websites. Thought I would ask and see if any of you were big fans of any particular PEAR libraries and if you recommend I learn and use them? Thanks for any input or suggestions.
Posted: Sun Mar 18, 2007 8:59 am
by Chris Corbyn
I personally don't link it. It seems like a lot of projects pop up and them just disappear from nowhere. I occassionally looks up small snippets as reference but that's all. I've seen some pretty poor PEAR code too (the IMAP package for a start). It's a brilliant idea, but I just don't personally think it's all it's cracked up to be.
Posted: Sun Mar 18, 2007 9:02 am
by jayshields
The only one I've ever used is the benchmarking one for timing script execution. Seems OK to me...
Posted: Sun Mar 18, 2007 9:23 am
by alex.barylski
PEAR....pfffft...should be called lemon cause thats about all you get
This is of course my own humble opinion

Posted: Sun Mar 18, 2007 9:29 am
by onion2k
I don't use it. You can't guarantee it'll be available, and so many PEAR libraries depend on so many others that you can't selectively include things very easily. That said, I do have a local copy, and I do occasionally lift functionality from it if I can 'un-dependency-ize' it quicker than writing my own version.
Posted: Sun Mar 18, 2007 1:06 pm
by Christopher
PEAR has a lot of good code, talented programmers, even a good packaging format, so it in instructive to understand why it is widely avoided and has been dropped from the PHP distribution.
Although there is a lot of good code in PEAR, it suffers from something that is epidemic in PHP -- bad design. You can look at PEAR as the poster boy for making poor architectural design decisions and sticking with them. I am not sure whether it was Group Think or the fact that they thought they were right because they had the PHP imprimatur. They certainly were partly responsible (through ignorance, not maliciousness) for the sorry state of OOP in PHP for many years, as well as visible evidence to support criticism of PHP.
Things like Ruby on Rails showed, first and foremost, what good design could be. It certainly lit a fire under PHP framework designers -- with older projects dying and many new ones starting. You could see the chains of PEAR and its kind of thinking dangling from the Zend Framework as it lurched into existence. The ZF has shaken off many of those chains, but there are still a few around, hopefully to be fixed in 1.1 or 1.2.
It is difficult to qualify these problems, but I would suggest that when a project goes for convenience rather than sticking to simplicity and purity, that is when these types of design problems appear.
Posted: Sun Mar 18, 2007 3:55 pm
by seodevhead
I had a feeling I would be getting a lot of these kinds of 'takes' on PEAR. Eventhough I'm rather amatuerish w/ PHP, from what I have seen so far of PEAR just seems a bit antiquated.
I would however like to utilize some php classes... so it sounds like Zend Framework is generally considered the framework of choice right now, correct? All the others seems to be so bias to the MVC (which I don't want to use), but there are some classes in the Zend that I am looking at that look very promising.
Posted: Sun Mar 18, 2007 4:29 pm
by John Cartwright
Indeed, if you don't want to use the full blown MVC implementation of the Zend Framework then you don't have to. It is very simple to utilize particular components.
Posted: Sun Mar 18, 2007 5:30 pm
by Ambush Commander
I would definitely use the PEAR installer. It is a pipe dream was you get to know how to use it, have command line, and create your own local repository.
However, with production code, I don't touch PEAR modules with a ten-foot long stick. Too much of a control freak, I guess.
Posted: Sun Mar 18, 2007 5:51 pm
by Maugrim_The_Reaper
PEAR is worth using but it suffers from its original packaging, rules, requirements and internal running. It's a huge shame since it could have become a powerhouse for reuseable code where innovation, and improvement were encouraged. The code itself is a mixed bag. There are some truly good components, and some bad ones, PHP4 and PHP5, good OOP and atrocious OOP. At the end of the day its so inconsistent and restrictive that it's actually a lot easier to find a much better external class or library which was allowed to evolve more naturally away from PEAR's rules. Folk here have developed some such - HTMLPurifier and SwiftMailer for example are two libraries I know of which are impressive, high quality and well worth looking at. What does PEAR offer in competition? Take a look at the PEAR::Mail packages...
I would however like to utilize some php classes... so it sounds like Zend Framework is generally considered the framework of choice right now, correct? All the others seems to be so bias to the MVC (which I don't want to use), but there are some classes in the Zend that I am looking at that look very promising.
The ZF is still far behind most PHP frameworks - you'd have to wait until long after 1.0 to see its full impact since that's the version we expect to see a stable API. Up until now most users have only made small, easily changed, applications. I wrote a blog app for example, and a small chat application among others - anything bigger could be risky unless it has the backing of extra resources/time to handle the near-certainty of future refactoring needs.
That said it's best characteristic is that classes can be used in isolation. There's quite a selection to choose from. Of course Zend Framework also play nice with other libraries. I've been using SwiftMailer instead of Zend_Mail for a while now and haven't had any problems.
There is a bit of a price involved - there is a bit of coupling to classes like Zend, Zend_Uri, etc. Most of the time it's an inconvenience you just need to be aware of since such classes tend to be called statically since the developers didn't favour composition for such usage. Sometimes it can be plain annoying but until developers learn to avoid static class because they're "easier" we're stuck with it. Zend_Uri::check() - bleh! It's everywhere!
That aside, it's a good place to look, alongside PEAR, and Sourceforge/Freshmeat.