Re: Mail_IMAP 2.0.0 alpha 1
| From: | David Costa | Date: | Wed, 07 Jul 2004 01:39:27 +0000 |
| Subject: | Re: Mail_IMAP 2.0.0 alpha 1 | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-31690@lists.php.net to get a copy of this message | ||
On Jul 7, 2004, at 2:12 AM, Greg Beaver wrote:
David Costa wrote:Why no need to chose ? there is a PEAR_Exception class, so pardon me but as far as I know I can still chose to use PHP 5 properly vs something else, this will all the due respect for your tremendous effort to make PEAR a better place and for which I am (and many other developers) very grateful. I am not sure what does a smooth transition is in your book when we can't a) include ANY PHP 4 in a PHP 5 package b) current PHP 4 packages can't go PHP 5 but they will need a new version if/when will be appropriate if we are talking about the developers transition, well I do think that every PHP 5 developer with a minimal experience knows how to handle exceptions. If not he could simply ask (as I did, thanks to Hans and Mike for the support).snipNo need to choose - the *point* of PEAR_ErrorStack is to co-exist with exceptions and provide some functionality that exceptions lack, while providing a smooth transition from PHP4 to PHP5.@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...just jumping into this, I don't think we should force errorStack vs exceptions in PHP 5.
PEAR_Exception is php5-only, obviously. PEAR_ErrorStack allows packages to MAINTAIN BC with PEAR_Error OR use exceptions WITHOUT A REWRITE.I don't think so. If you port a PHP 4 package to PHP 5 just for the sake of a quick hack, then you are probably right. But if you want to do a serious porting you will have to live with PHP 5 new object method, like it or not. I ported Savant 1.5 as a quick hack to PHP 5 E_STRICT and I just had to exclude PEAR, replace PEAR::Errors with exceptions...et voilà
Combining the two packages into something that accomplishes both goals is a good answer to this problem. Pardon my french: let's cut the either/or bullshit right now.Well In the previous discussion with Aidan you where probably right with the tone but my current messages doesn't warrant this pub-alike jargon ;) Without a smiley I will take your statement as serious and there is or was no bullshit whatsoever in this discussion. Unless you think that PHP 5 is bullshit and that's a different story...but as I am fairly confident that this is not the case you can read my message under the Exception misinformation topic where I show how a PHP 5 core build-in class ( the Sqlite OO wrapper) uses exceptions.
I will only say this once. This is the last message I will send regarding basic PEAR_ErrorStack functionality or usefulness. Anybody who wishes to start a polemical war MUST reference specific line numbers in the code for me to pay any attention in the future.I don't, in fact there is no war. I think you are getting too emotional and arguments like "I will only say this once" don't really demonstrate much to me. Getting back to the reality scenario, I finished two PHP 5 only packages. PEAR_ErrorStack is not PHP 5 compliant so I used PEAR_Exception. Feel free not to like this approach but you can't impose something on the grounds that you feel is better then the mechanism provided by the new object model. Pear_Exception is completely fine and everyone who have currently used PHP 5 in productions environment might probably agree with me. Eventually, this message is not meant to be an insult to your work or your package (this is pretty obvious but you never know). I would have preferred to leave it as it is but the cut the bullshit bit and say it only once was kind of too much. Cheers David Costa