Re: Mail_IMAP 2.0.0 alpha 1

Klaus Guenther wrote: >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. The package in question is Mail_IMAP not Net_IMAP :) I just think it is not very cool to move from 1 to 2 after a only few weeks of stable state, without trying to improve the current API first. This looks like the easiest way and I am a bit concerned about this becoming an habit. >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. This does not mean I have to use it AFAIK. I feel that it is not needed for PHP5 packages unless you need to add a compatibility layer for PHP4 or you need some extra features you think users can't handle themselves (for example logging warnings). In other cases, it will add overhead. >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. Yep, feel free to use it people :) >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. I understand your concerns but what I will try to do is simply use what PHP5 provides, nothing more nothing less. If it provides the right tools, there shouldn't be a need for Yet Another Error Class. >PEAR_ErrorStack(2) and PEAR_Exception should be required for >error/warning/exception handling. I am fine with PEAR_Exception as long as it does not deal with warnings, just exceptions (as the name states). Bertrand Mansion Mamasam