SitePoint Sponsor

User Tag List

Results 1 to 11 of 11

Thread: PEAR pro/cons

  1. #1
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    San Diego
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    PEAR pro/cons

    I was looking at using PEAR DB and DB_DataObject related stuff. I've heard bad things about PEAR in general. I was wondering if anyone had anything to share.

    I've been using ADOdb a lot. Is there any LGPL (or equiv) object-relational library that interfaces with it?
    Kyle Maxwell

  2. #2
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There is nothing bad about PEAR. But you need to remember the caveat that PEAR is something between framework than a script archive. Because they are meant to work together, many are not as clean a stand-alone alternatives. Conversely PEAR is not tightly coupled enough to compare well with real frameworks.

    WACT and several other frameworks can use ADOdb and provide Data Object features.

  3. #3
    SitePoint Enthusiast m0n5t3r's Avatar
    Join Date
    Jul 2003
    Location
    Romania
    Posts
    49
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like building standalone applications, so PEAR doesn't fit in my way of work, but it can be a life saver if one needs fast development in a controlled environment.
    m0n5t3r's nest
    --
    earth is 98% full ... please delete anyone you can.

  4. #4
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You cant find similar packages where the probability is great that those still exists in 5 years (and maintained). What is often missing are end user docs.

    I cant await the first stable release of the pear db layer "mdb2" in focus to php5.

  5. #5
    SitePoint Zealot
    Join Date
    Sep 2004
    Location
    new york
    Posts
    113
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    m0n5t3r, what package would you recommend for building standalone applications? Would ADOdb be better than PEAR?

  6. #6
    SitePoint Member
    Join Date
    Oct 2004
    Location
    Sheffield, UK
    Posts
    17
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    AFAIK ADOdb is no different to PEAR in the respect it's just a DBAL (Database Abstraction Layer). It provides a common API to talk to "any" RDBMS so you can easily switch the back end used by your site.

    Why us a DBAL? It means no re-coding if you switch backends

    Now, many stand alone projects, or internal projects, or one off bespokes are never going to change their backend. So you wouldn't use any DBAL, because a DBAL adds overhead (load the class, parse the class, execute the methods...) wheras directly using the RDBMS you wish to use via the standard PHP functions (mysql_* mssql_* etc) is faster.

    If you are writing something for public consumption, such as vBulletin, PHPBB, Geeklog etc, you want an abstraction layer because people will run against numerous different databases, you don't want to tie your users to a single RDBMS.

    AS for PEAR::DB vs ADOdb

    ADOdb has benchmarks posted which suggest it is much faster than PEAR::DB, however, I've seen benchmarks posted round here from lastcraft (I think, or was it salkirk or someone...) showing that if you go to the full outer level, there is more of ADOdb to load in and it is actualy slower.

    However, I'm not sure if that was benchmarking ADOdbEXT (There is a C code extension that puts part of ADOdb into C and thus makes it faster, it's not an interpreted module any more) or plain ADOdb.

    I've only used PEAR::DB myself, I find it quite nice. I'm trying to find some objective third party benchmarks of ADOdbEXT vs PEAR::DB to make my final decision for a new project.

    If changing RDBMS isn't on the cards, I'd tend to write a micro-DBAL in a class so that the DB code is easier to maintain and I don't have to write the same thing again and again. Then if I do ever have to swap database engine it is still easy to do it, but I do have to cut more code. Yet I haven't suffered the overhead of a big package like PEAR::DB with all the code I'll never ever use for PostgreSQL and Oracle and MySQL etc...

    Mike.

  7. #7
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It is really not that difficult to build you own database access class and then build data objects on top of that. The problem with PEAR and ADOdb is they use the kitchen sink approach. If you need all the features then use them; if not rolling your own is pretty easy. You can build the application specific classes I mention above (even an OR mapper) that are under 5k each. That's 15k which is a big difference from including DB_DataObject.
    You cant find similar packages where the probability is great that those still exists in 5 years (and maintained). What is often missing are end user docs.
    In 5 year you won't get backwards compatibility from any PEAR library so it doesn't really matter if a new version is supported.

    The true problem with PEAR is that they started out with bad base and error classes because they thougt they were an archive not a framework and have never recovered.

  8. #8
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In 5 year you won't get backwards compatibility from any PEAR library so it doesn't really matter if a new version is supported.
    I'm not talking about backward compatibility. It is absolutly clear that we cant expect from any package that it should be backward compatible to 5 year old versions.

  9. #9
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Pear is a train wreck. Avoid.

  10. #10
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by arborint
    There is nothing bad about PEAR.
    Cough...

    How about big bloated classes, very little testing, very little documentation, a dictatorial attitude to the application developer and almost no reuse. There is a lot of good stuff in PEAR, but these are brave attempts to rise above the base classes.

    At least they are trying to fix the testing part now, but there is a lot of buggy code tucked away in there (as elsewhere). It's really a package library, more like CPAN. About CPAN quality, perhaps a little lower. My own first port of call is usually Sourceforge.

    I would follow this approach...

    1) If a library is not central to your project, that is supplies core value, then using a package will be fine. Wrap it and test it, but otherwise it should be OK.
    2) If it's core to your business then roll your own. This is known as the "segregated core". You just don't want to depend on anyone else's code for critical features unless you have good support and it's flexible enough. One technique is to import the package as a cut and paste exercise into your source control and then go your own way. This allows you to strip out features you don't need.
    3) Low level stuff you use all the time can be got from other places such as PHPClasses or Sourceforge. You usually want smaller classes for this kind of stuff, not packages.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  11. #11
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't think PEAR is bad and I think there are a lot of good people working on it. I just think that PEAR has not acheived anywhere near what it's potential was. PEAR was a great opportunity to set a direction for the PHP community. They ended up being more divisive than being leaders. If they had been more interested in the working with the leading developers in clarifying interfaces and architectures that work in PHP they could have done a lot more good. Now they are just their own little cabal who has alienated lots of developers who have gone off to do their own thing. The sad fact is that most of the interesting work is being done outside of PEAR. That's why people go to sourceforge or phpclasses first. The PEAR folks are satisfied with what they are doing so they will continue to be part of the landscape.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •