On Sat, 2005-06-25 at 11:06, Matthew Weier O'Phinney wrote:
> * Robert Cummings <robert@xxxxxxxxxxxxx> :
> > On Sat, 2005-06-25 at 10:32, Matthew Weier O'Phinney wrote:
> > > * Catalin Trifu <catalin@xxxxxxxxxxxxxxx> :
> > > > I also tend to stay away from PEAR, which is kinda bloated for my
> > > > taste, except the Log package.
> > >
> > > <rant>
> > > I hear that a lot on this list, and I don't understand the reasoning
> > > behind such comments -- perhaps because nobody offers any reasoning,
> > > only the opinion?
> > >
> > > I'm a PEAR user, and I've found the packages anything *but* bloated.
> > > Granted, I only use a subset of PEAR, but that subset has made mycoding
> > > easier. I use DB, Log, Mail, Mail_MIME, HTML_QuickForm, Cache_Lite, and
> > > Pager daily; additionally, we use custom PEAR error handlers to catch
> > > errors generated by these packages, log them, and display custom error
> > > pages. If I'd had to write the functionality I have readily available in
> > > these packages, I wouldn't have a job right now. They've helped me meet
> > > numerous deadlines.
>
> It may be my opinion, but I've also given some reasoning for my opinion:
> help in meeting deadlines, centralized error handling, and variety of
> packages. I've helped to *qualify* my opinion. I'll do more of that
> below.
Your argumentation is flawed, you are using a red-herring technique to
justify how PEAR is not bloated by giving examples of its usefulness. I
give no argumentation either way as to the usefulness of PEAR. I have
used PEAR and continue to use PEAR as I see a need; however, that
usefulness has ABSOLUTELY NO BEARING on whether it is bloated or not.
Now so far you have said the following:
- I use such and such a package in PEAR
- I wouldn't have a job if not for PEAR
- PEAR has helped me meet deadlines
- centralized error handling
> > No matter how many deadlines PEAR helps you meet and how much you may
> > find the PEAR modules indispensable, you are expressing a subjective
> > opinion unrelated to the OP's comment about bloated. A package can be
> > very bloated and still be extremely useful to someone who doesn't have
> > the time or the ability (not to say you don't have the ability) to
> > implement similar functionality themself.
>
> Correct; ability isn't the problem; time often is.
- ability isn't problem time often is
> <aside>
> However, I also find that I start by creating some functionality myself,
> and then as special cases start popping up, modifying, adding on... and
> then discovering that an equivalent PEAR package already exists that
> covers all these special cases and a number I hadn't thought of. (Pager
> comes to mind).
- pear often already has equivalent code
- covers all these special cases
> I often wonder if what is meant by 'bloat' is that those claiming
> 'bloat' feel that the PEAR code covers too many special cases -- cases
> they have not encountered or do not expect to encounter.
>
> Personally, I feel that I'd rather have all my bases covered; I can see
> a point in wanting to keep code trimmed to the necessary cases, though.
> </aside>
>
> > Additionally PEAR does present a centralized location for common
> > functionality with good peer review,
>
> This is one of the selling points for PEAR; many eyes looking at the
> code, including people who aren't invested in the particular problem.
> Having the diversity of reviewers often makes for better code.
>
> > however IMHO I side with the OP with respect to much of PEAR being
> > bloated.
>
> Then explain what you mean by 'bloated'. Just throwing out that phrase
> doesn't give anybody any extra information -- just your opinion. Can you
> give some examples to *qualify* your statement that PEAR is bloated?
> That was the main thrust of my rant -- people throwing out unqualified
> opinion statements like 'PEAR sucks' or 'PEAR is bloated' without
> explaining *why*.
So far all the reasons you've given to indicate why PEAR is NOT bloated
have nothing to do with why PEAR is or is not bloated. You have clearly
indicated a passion for it, a usefulness from it, even established a
decent amount of superiority in it, but if anything your arguments have
indicated why it is bloated in many respects:
- covers all of these special cases (and by virtue probably more)
- I can see a point in wanting to keep code trimmed to necessary
cases though
- rather have all my bases covered
It is my opinion and the opinion of many others that the fact that PEAR
covers so many exceptional cases, the fact that PEAR implements such a
generalize error handling system, the fact that PEAR do so much generic
everything to make everone happy, that these elements that make it so
versatile also make it feel bloated. It's like kicking a soccer ball to
the goal, but rather than take the most direct route, you take the
fringe route to cover all your bases...ultimately this is generally a
longer path.
Now that I've given examples of why bloated please refrain from giving
subjective measurements of gratitude over arguments that would indicate
how it is NOT bloated. Don't forget, I've never once said it wasn't
useful, or even a must-have for many pojects, but it is quite far form
lean, mean, processing machine IMHO.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
