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