Re: [PEPr] -1 for RFC::Prefix all classes with PEAR_

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 4, 2006, at 11:39 AM, Arnaud Limbourg wrote:

We will not upgrade existing packages, this rule would apply to new packages. This would be terrible for BC. Waiting for namespaces is a bad strategy. New packages have to be PHP5 anyway so this proposal does make sense as it applies to new packages or maintainers who want to prefix, in which case this would need to be a new Package2. What do you have in mind for Pear and PHP5. A PEAR2 installer that works only in PHP5 ? (don't mean to sound dry, it's just a question :) As I have stated before, I think PEAR needs to re-focus on the installer and utility classes which make native PHP code more usable. The PEAR class itself is worthless - everything interesting it does has been implemented in PHP natively.

I will speak in fairly broad terms here about the direction I feel we should proceed. I think we should: - - Support only PHP >= 5.0.x. Depending on the length of time it takes to get things going, we might want to target 5.1.x. - - Ditch the current PEAR class entirely. It doesn't do anything that PHP itself doesn't do these days. - - Come up with / settle on ONE error handling method. The current proliferation of error checking is ridiculous; we have: true/false return values, PEAR_Error, PEAR_ErrorStack, exceptions, PHP's native errors, and trigger_error(). - - Focus on the installer, and make it the #1 way to install *any* PHP-based library or application. Ideally, I would like to be able to package up an entire site as a PEAR package, and have deployment be as easy as "pear install MySite-1.0.0.tgz". I believe that this is possible with custom file roles in the current installer, but it's not very well documented, and definitely not easy to make happen. - - Do interesting things with the modern features of PHP. Packages I'd like to see (but haven't had a chance to start working on) would be: - A database wrapper around PDO, which provides convenience methods akin to DB/MDB2, but lets PDO handle the heavy lifting. - A replacement for HTML_QuickForm which uses DOMDocument to build it's forms instead of HTML_Common. Sane handling of groups and improved rendering code would also be a big win. - - Support for Subversion in the dev tools, i.e. "pear svntag" - - Clarify CS for the new features in PHP 5, like class constants, interfaces, and so on. - - Create a new PEAR class which handles package instantiation / configuration / initialization, somewhat similar to Yawp. I.e. a config file to set package parameters (DB's default DSN, Log's log file, and so on) and a class to load and instantiate the package. E.g. I could have an INI file like: [Log] backend = flle file = /tmp/debug.log Then do: $log = PEAR::singleton('Log'); and get your Log instance back, ready to go. And for you PEAR_ prefix purists, this will allow us to abstract out the file paths and class names; the loader can know that you need a PEAR_ prefix to the class, file path, or whatever - and it can be changed there without breaking other code. I know that this may not work well for absolutely every case, but it would ease the pain for 95% of them, and people could still load up classes manually if need be. In short: make PEAR the #1 toolkit for developing and deploying modern PHP code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFJBmMxuUdPD6j2IMRAiLtAJ9gHAfftw5+fkOdhBP/S0iDp+LCuwCeN4nj 9KFmgpqZ+rkQFEk/TPmXwHY= =tPHl -----END PGP SIGNATURE-----