@Chris: chances are the PEAR packages you had been using were not stable releases – once a package has been released as stable it must remain backwards compatible in every future release.

Also it is very easy to set up individual PEAR installs in common hosting environments; steps required for doing this are detailed at http://pear.php.net/manual/en/installation.shared.php and are also useful for situations where you perhaps do not have permission/access rights to update or install new packages to an existing PEAR install on a certain machine.

Regarding abandoned projects – it is true that there are a number of orphaned packages in PEAR – in fact a list of them is available at http://pear.php.net/qa/packages_orphan.php – the PEAR Group and QA teams adopted a mechanism for other developers to assist in maintaining those packages and potentially take over responsibility for them. This is outlined at http://pear.php.net/manual/en/newmaint.takingover.php

PEAR itself is, I think, framework agnostic; it certainly isn’t what some would term a full-stack framework such as Symfony, CodeIgnitor or CakePHP; it is PHP’s equivalent to Perl’s CPAN (http://www.cpan.org/ ), Ruby’s gems ( http://docs.rubygems.org/ ), and Python’s eggs ( http://www.python-eggs.org/ ).
(It is also an install mechanism – popular and reliable enough for many frameworks to be installable via the PEAR installer; solar, zend, symfony are just a few that can be downloaded and installed via PEAR.)

This actually leaves plenty of room for PEAR packages to do some of the grunt work required by various frameworks and also gives the benefit of only having to fix a certain bug once – rather than having to solve/fix them a multitude of times depending on what framework you’ve used for the project in hand.
Fix a bug, send the patch upstream and never have to worry about it again – sounds good, eh?

The quality per package seems to vary a lot… and sometimes the project owner seem to have abandon the project. Not to mention that most hosts do not have PEAR installed..

It is not without a reason most frameworks come with their own solutions… even ZEND ^^

http://framework.zend.com/manual/en/zend.validate.html

Validation should be a part of any framework to my opinion

However, as the subject and content of my post indicated, I was addressing a deficiency with the CakePHP framework’s postal validation code. So, my solution is based on the existing Validation::postal() method that comes with CakePHP. The regular expressions are taken from that method. So, while PEAR is a good solution, it was beyond the scope of my article to suggest scrapping Cake’s entire Validation class in favour of another library.

So, I didn’t “spend time writing and debugging regular expressions, compiling lists of valid data and so on” – you can thank the CakePHP team for that. I simply built upon their work.

And, Ollie – I’m not “ignoring lightly” the “massive amount of detail work donated by the diligent and progressive user community”. I’m part of the equally diligent and progressive CakePHP user community, so I’m building on that.

Anyway, thanks for the response Ken – it did give me something to think about. If I had the time I would consider replacing Cake’s Validation class with a more robust suite, but it’s just not in the cards right now.

Adding a new Validate_XX package to PEAR is not a huge undetaking, either. It stands a better chance of surviving in the long term than a one-person validator script.