Page 1 of 4

Come to the PEAR-fest

Posted: Sun Jan 25, 2004 7:00 pm
by ilovetoast
First, this is meant in a light-spirited way. I am not a PEAR zealot and I really don't care to engage in anything resembling a heated discussion of the issue. If you think PEAR sucks, fine by me. If you think PEAR roxxor, fine by me. I will still sleep well either way.

I have seen it several times in my short time here: people not-loving PEAR. I'm curious why? So spew away please. Everything you can think of for why you hate/don't love PEAR. To be honest, I normally wouldn't bother with this question in a PHP forum, but there seem multiple experienced, non-PEAR users here. ;)

Please group your complaints if possible, as my pedantic nature would appreciate that. I'm really looking for non-admin, non-install, non-nooblar complaints (as I don't use those pieces/functions/stuff).

I have no intention of refuting or attempting to refute any complaints -- including any silly or misinformed one, though I may ask clarifying questions.

peace

i dropped the toast

Posted: Sun Jan 25, 2004 8:55 pm
by BDKR
It's just heavy. As an example, if you take a look at the PEAR quick forms class that came up in a recent conversation, you'll see that it's doing some pretty tricky stuff 'inside the box' that's prolly not needed.

In Quick forms, you would use

Code: Select all

# I'll use underscores to drive the studly caps zealots mad!
$quick_form->addElement();
to add any type of form element (radio, text area, password, etc...) to the form. Now this does make it somewhat easier to use up front, but the algorithmic twists and turns it has to do in the back end to support this are huge. Actually, it doesn't have to do them, they seem to have chose to do them.

Anyway, each call to ->addElement() will most likely call another one called _loadElement() WHICH ACTUALLY CREATES AN OBJECT FOR THAT ELEMENT! In other words, a quick form object is maintaining awareness of it's elements via an array of objects that it instantiates internally.

Now while this works, it's of questionable reason considering we are in a web environment.
Not only did we allready have to suffer the hit of parsing QuickForm.php (which is over 1700 lines long!), Common.php (over 1500 lines), and PEAR.php (over 900 lines), we also have the nested instantiation of objects (which also incurs the overhead of a file include and parse for each new type added) QuickForm itself.

This is a lot just for a web page that's going to go away real fast like. And many of the rest of the PEAR classes follow a rather similar line of reasoning in their designs.

On the other hand, this would be OK if it was being used in conjunction with something like an application server (a sandbox) where these objects could be persistent. Perhaps SRM and/or Continuity will someday step up to the plate.

Anyway, a lot of people will support this as they've bought into the idea that there is no way to produce clean, easy to maintain, re-usable, procedural code.

Well, I'll stop here as I've got some reports to finish for work tomorrow.

Cheers,
BDKR

Posted: Mon Jan 26, 2004 2:21 am
by jason
I have a class in PEAR, so what can I say? It does what it was meant to do, and that's really it.

BTW, it's the Image_Color package.

But why don't I use PEAR? There is a LOT to PEAR, and if you are going to use one part of PEAR, you pretty much lock yourself into using PEAR.

For example, I can't just take a small class out of PEAR and use it some place else, mostly because it requires 20 other classes.

That's my biggest beef with PEAR.

Posted: Mon Jan 26, 2004 3:26 am
by qads
hmm..well, i never use it cos i find my own code more useful, i can port it to any other project i want at any time, if something doest work then i know whats wrong and where need to edit it. in other words, i hardly use other people's code i guess.

Posted: Mon Jan 26, 2004 8:46 am
by elmonty
I'm not pro-PEAR or anti-PEAR. However, there are some things in PEAR that you can't find anywhere else. For example, a class for extracting all the parts out of a MIME email.

If anyone has a non-PEAR solution to this, I'd love to see it.

Posted: Mon Jan 26, 2004 5:23 pm
by BDKR
elmonty wrote:I'm not pro-PEAR or anti-PEAR. However, there are some things in PEAR that you can't find anywhere else. For example, a class for extracting all the parts out of a MIME email.

If anyone has a non-PEAR solution to this, I'd love to see it.
I wouldn't be suprised if one exists at phpclasses.org. There are tons of things there that I don't see in PEAR. There is even a class to emulate threads!

Cheers,
BDKR

Posted: Mon Jan 26, 2004 5:42 pm
by elmonty
BDKR wrote:I wouldn't be suprised if one exists at phpclasses.org. There are tons of things there that I don't see in PEAR. There is even a class to emulate threads!
The one at phpclasses.org is the same one that is in PEAR.

Posted: Mon Jan 26, 2004 6:41 pm
by patrikG
elmonty wrote:
BDKR wrote:I wouldn't be suprised if one exists at phpclasses.org. There are tons of things there that I don't see in PEAR. There is even a class to emulate threads!
The one at phpclasses.org is the same one that is in PEAR.
But as a stand-alone class, not with all the overhead. If PEAR was well-coded and you could pick the bit you want from it: great. The problem, as outlined above, is that PEAR isn't.

Posted: Tue Jan 27, 2004 8:41 am
by elmonty
patrikG wrote:
elmonty wrote:The one at phpclasses.org is the same one that is in PEAR.
But as a stand-alone class, not with all the overhead.
Not true. They both include, and descend from, PEAR.

Posted: Tue Jan 27, 2004 8:50 am
by Nay
Speaking of PEAR makes me hungry. I've never used PEAR so I wouldn't know. I'm a total loser when it comes more into OOP so I stick to proceedural programming.

-Nay

Posted: Tue Jan 27, 2004 11:41 am
by BDKR
Nay wrote:Speaking of PEAR makes me hungry. I've never used PEAR so I wouldn't know. I'm a total loser when it comes more into OOP so I stick to proceedural programming.

-Nay
A looser? I don't think so. While OO is NOT an end all, it's good and has it's use in many places. You'll get it. Just don't make a religion out of it.

Cheers,
BDKR

Posted: Tue Jan 27, 2004 11:57 am
by xisle
qads wrote:hmm..well, i never use it cos i find my own code more useful, i can port it to any other project i want at any time, if something doest work then i know whats wrong and where need to edit it. in other words, i hardly use other people's code i guess.
this would be my opinion as well..

Posted: Tue Jan 27, 2004 4:41 pm
by patrikG
elmonty wrote:
patrikG wrote:
elmonty wrote:The one at phpclasses.org is the same one that is in PEAR.
But as a stand-alone class, not with all the overhead.
Not true. They both include, and descend from, PEAR.
My knowledge of PEAR is not extensive and mostly based on what I looked at about 8 months ago when I looked at a number of PEAR classes. My prejudice against PEAR since then has been as described above. Yet, I recently, i.e. two days ago, thought I'd give that benchmark class a shot again. After downloading it I discover that it depends on the PEAR base-class (weighing some proud 20k).

All that, 20k of useless code, to simply output: "This script took xx amount of seconds to parse." Sorry, but in terms of performance and resource-friendlyness, I find PEAR severely lacking.

I found my judgement from 8 months ago confirmed.

Posted: Tue Jan 27, 2004 7:16 pm
by ilovetoast
Thank you all, for the well-thought out replies. After my last project concludes on Jan 31, I'll be working for myself finally.

I plan to abandon PEAR, but retain some ideas of the PEAR_Error model in my work. I won't move to PHP 5 for some time; read:after it's been proven stable by someone else. ;) So, I need a try-catch kludge in the interim and a paired down PEAR_Error is just what the coder needs.

A PEAR complaint I have long-had, in addtion to the bloatware issue, is the error-overkill issue.

* 5 error mode constants? Only two are needed in PHP4 and that's if you use callbacks.
* Required backtraces on every PEAR_Error? That's a good resource expenditure.
* 3 error modes that expose the user to PHP errors? Why handle errors at all then?
* Expected errors array with a pop,push, and 2 del methods? It's debugging gone crazy.
* Different error handling modes/methods - see previous.
* One of the silliest methods I have ever seen - throwError. If I need a laugh I just read this method and chuckle.
* Error prefixes AND messages? bloooooooooooat.

The PEAR_Error class has always felt to me like a nice simple try-catch pseudo-emulation that has been polluted by a bunch of debugging code.

Anyways, thanks again for all the comments.

peace

ilovebobthetravelinggnome

Posted: Wed Jan 28, 2004 12:47 am
by lazy_yogi
Are you gonna make your error classes public ? :)

A try/catch emulation that would be easy to switch over propper try/catch when php5 comes would be a nice soln.

Cheers,
Eli