Re: The Nature of PEAR's Greatness

> Tell the list, what do you think is great about PEAR? > > * The installer is great. The installer is fantastic! The more familiar I've become with PEAR, the more I've been thinking about moving all my contract development over to PEAR package format. It's really a slick system, and one that I find much more friendly than CPAN's command-line installer. > * Coding standards rock! If only, if only, if only more developers out there would stick to something like the PEAR coding standards. I've been writing PHP-based sites and projects professionally since PHP 2.0b6, and in that time I've worked on many projects with a variety of coding styles, and have had some shift in my own stuff as well. Having a guideline like the PEAR coding standards really helps me to be more disciplined in all my work. I, too, found the "tabs vs spaces" conversion challenging at first, but I'm now grateful for having been nudged in that direction by the PEAR coding standards. Hats off to the PEAR team for having the balls to set something like this in stone, and for sticking to their guns on it. > * I like the idea of a common error handling scheme. I LOVE THE IDEA. I'm especially eager to get into Error_Stack. > * The categorization of classes, while it might use some work, is very > helpful. Of course! Imagine what PEAR would be like if there wasn't any categorization! : ) It might use some work, but I think that on the whole the categorization is good, and helps to steer newbies in the right direction. > * The structure of classes (tests/, docs/, etc) is very useful The structure of packages is great. Again, as a "lone wolf" contractor, I find that by having chosen to adopt the PEAR structure into my work, I can more readily see what needs to be done in my work. If I'm writing a component for a client, and my "docs/" directory is empty ... Well, as much as I'd like to be done, I'm not. : ) I think that the structure imposed by packages is overall very helpful (but to eek in a constructive comment -- it would be great if all the packages had a "fleshed out" structure here!) Currently the structure feels like a very nice promise that is awaiting fulfillment in many packages. > ... I'm sure there's more, let me think about it ... The biggest thing that I think it worth mentioning about PEAR that may be difficult for some to see from the inside is that it's become The Standard (ala CPAN). I read some of the references in the "natural selection" thread this morning, and there's some jibba-jabba in there about people forking off PEAR in some new direction, with a new class library, etc... Have fun, I say. Pick up any current PHP book, and a good chunk of the examples you'll find within use some bit of PEAR code. (Thinking of _PHP Cookbook_, _Essential PHP Tools_ and _Advanced PHP Programming_ right off the top of my head ...) Consider that people just coming to PHP or people who are looking to expand their PHP knowledge are likely to purchase one or more of these books. When they dig in to the examples in those books, they'll be coming to PEAR. Perhaps they'll shop around and try ADOdb (I did) ... But eventually, I think people who are interested in writing truly portable/flexible/"as close to standards as we've got" code are going to come back to PEAR packages, for better or worse. So -- for whatever warts it may have, PEAR is the place for me. I eagerly await the future expansion of the project, and I view the current debates as sort of an adolescent hormone-laden growth spurt that any project experiences as it moves from its origins into a more mature project. Onward and upward, folks! PEAR is an awesome collection of work, and I continue to be excited about incorporating PEAR code into my own projects. Finally, I look forward to contributing a couple of bits of my own ... Now that I've officially emerged from wallflower status, I'll have to wrap up my proposals on a few packages I've got cooking! Hats off to all involved! - Clay (longtime listener, first time caller) -- Killersoft.com