Come to the PEAR-fest

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

ilovetoast
Forum Contributor
Posts: 142
Joined: Thu Jan 15, 2004 7:34 pm

Come to the PEAR-fest

Post 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
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post 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
jason
Site Admin
Posts: 1767
Joined: Thu Apr 18, 2002 3:14 pm
Location: Montreal, CA
Contact:

Post 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.
qads
DevNet Resident
Posts: 1199
Joined: Tue Apr 23, 2002 10:02 am
Location: Brisbane

Post 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.
User avatar
elmonty
Forum Newbie
Posts: 13
Joined: Tue Jan 20, 2004 9:52 am

Post 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.
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post 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
User avatar
elmonty
Forum Newbie
Posts: 13
Joined: Tue Jan 20, 2004 9:52 am

Post 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.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post 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.
User avatar
elmonty
Forum Newbie
Posts: 13
Joined: Tue Jan 20, 2004 9:52 am

Post 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.
Nay
Forum Regular
Posts: 951
Joined: Fri Jun 20, 2003 11:03 am
Location: Brisbane, Australia

Post 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
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post 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
User avatar
xisle
Forum Contributor
Posts: 249
Joined: Wed Jun 25, 2003 1:53 pm

Post 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..
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post 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.
ilovetoast
Forum Contributor
Posts: 142
Joined: Thu Jan 15, 2004 7:34 pm

Post 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
User avatar
lazy_yogi
Forum Contributor
Posts: 243
Joined: Fri Jan 24, 2003 3:27 am

Post 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
Post Reply