is PEAR the next CPAN or not?
Moderator: General Moderators
is PEAR the next CPAN or not?
I've been doing a lot of reading about PEAR and it's viability as the standard set of libraries for PHP. Anyone even remotely familiar with perl is aware of CPAN and the amazingly huge set of libraries it provides. One of the factors keeping PEAR from obtaining the widespread acceptance that CPAN has, is b/c so many PHP developers are writing their own classes to do the various tasks. Presently, I too use my own database abstraction layer as well as my own custom authentication/authorization system. PEAR has their own of each of these, but I don't particularly like them. I'm curious to see how others in the community feel about PHP library sets, primarily PEAR (although there are others such as phplib). Do you see it gaining the widespread acceptance that CPAN has? why || why not?
Well when i started three years ago PEAR wasn't too mature. None of the DB abstraction layers looked good. DB was bloated beyond efficiency ADODB and Metabase had problems as well. I made by own and have used it ever since.
I haven't evaluated PEAR since then, I probably should but it was a bad first impression.
I haven't evaluated PEAR since then, I probably should but it was a bad first impression.
There's also Eclipse http://www.students.cs.uu.nl/people/voostind/eclipse/.
..and an interesting discussion here: http://www.sitepointforums.com/showthre ... adid=93442
..and an interesting discussion here: http://www.sitepointforums.com/showthre ... adid=93442
I wasn't too impressed when I checked it out some time ago. I was looking for some inspiriation for a simple, straightforward template-class. The various PEAR-classes were too complicated, to bloated and way too heady.
I ended up writing my own template-class and have learned a quite a bit about PHP in the process.
I ended up writing my own template-class and have learned a quite a bit about PHP in the process.
Re: is PEAR the next CPAN or not?
Hi...
I am going to be less than flattering, because I have just wasted another four days with this "library". At any other time I would be more polite. PEAR people might want to skip this...
The problem is not that they are designed by a committee, but that apart from the author very few people review it at all. It's as if refactoring never happened. As a result nothing improves. There are no test cases and no way of testing before an install (even CPAN has that). Single author code tends to be quirky as well, hence classes having features bolted on that are of marginal concern at best. Even the PEAR writers themselves don't use there own library, judging by the level of reuse within it. The PEAR base class error handling is completely pointless and just adds obfuscation. A mess.
I may have another look in a year or so after PHP5, but in the meantime their official status is just blocking out alternatives. I think it should be revoked with PEAR fending for itself. PHP needs something better.
yours, Marcus.
I am going to be less than flattering, because I have just wasted another four days with this "library". At any other time I would be more polite. PEAR people might want to skip this...
Every time I use PEAR stuff I get bitten badly by bugs and unreadable source code. The last effort was the SOAP libraries. A combination of zero documentation and much mysterious behaviour nailed me that time. A look at the DataObject class code previously caused an immediate rejection. It would normally be a little unfair to point out specific examples like this except that I really haven't found anything I like enough to use.will wrote:why not?
The problem is not that they are designed by a committee, but that apart from the author very few people review it at all. It's as if refactoring never happened. As a result nothing improves. There are no test cases and no way of testing before an install (even CPAN has that). Single author code tends to be quirky as well, hence classes having features bolted on that are of marginal concern at best. Even the PEAR writers themselves don't use there own library, judging by the level of reuse within it. The PEAR base class error handling is completely pointless and just adds obfuscation. A mess.
I may have another look in a year or so after PHP5, but in the meantime their official status is just blocking out alternatives. I think it should be revoked with PEAR fending for itself. PHP needs something better.
yours, Marcus.