Re: Mail_IMAP 2.0.0 alpha 1

Bertrand Mansion wrote:

Richard York wrote:

2. I have completely rewritten the error API so that the package uses Pear_ErrorStack instead of PEAR, I've read on the list this is the successor to PEAR.php and packages should be moving toward it. I have very little experience with this package, is there anything about my PEAR_ErrorStack implementation that could be done better?

PEAR_ErrorStack is not the successor of PEAR_Error, it is just another way to do the same thing. You don't have to use it. Personnally, I am not going to use it, and I will also stop using PEAR_Error as it forces me to require PEAR.php. As soon as my packages will be ported to PHP5 E_STRICT, they will use standard exceptions and trigger_error(). In your special case, I find it a pity to break your API just to use PEAR_ErrorStack. I was using your package before, now I am in trouble.

Sorry, Bertrand, but it's not that dramatic. Because Net_IMAP 2.0.0 will be released as Net_IMAP2 2.0.0. So you can still continue using Net_IMAP. Also, I think you're mistaken when you say that PEAR_ErrorStack does not replace PEAR_Error. It was written for that very purpose and will completely replace PEAR_Error in the installer, etc. PEAR_ErrorStack is a very clean error implementation and when you port, you will be able to use PEAR_ErrorStack2 which will be completely E_STRICT compliant (the only thing that needs to be done for that purpose is replacing the var declarations with scope keywords and also prefixing the function declarations with scope keywords). There is no need to scare people that PEAR_ErrorStack is not php5 compliant. And I can't see anything more harmful in the long term than to implement your own error solution using standard exceptions and trigger_error. It will make it a nightmare for the users because the packages will all have their own way of dealing with errors rather than a standard way. Also, if QA needs to pick up maintainership of a package for any reason (e.g., the dev no longer wants to maintain the package), it will cause a huge headache to understand the error internals. PEAR_ErrorStack(2) and PEAR_Exception should be required for error/warning/exception handling. @Greg: Do you think you could port PEAR_ErrorStack to php5 sometime very soon so that devs can develop E_STRICT packages using PEAR_ErrorStack? I think it's about time for an error handling RFC... Klaus