separation of php4 from php5

Hi, I would like to suggest the solution to the php4/php5 problems that have been raised are substantial and have nothing to do with code. The two camps are: 1) PHP5 is a different language from PHP4. No script written in PHP4 can work in PHP5. No transition makes any sense. 2) PHP4 and PHP5 may be able to co-exist to help skittish users transfer their legacy scripts over to the new language. There are more users in camp one, so I move to ban any release that claims to work in both php4 and php5, and instead allow advertising that a script can FUNCTION in php5 and works in php4. Any (non-final as in non-application) script that supports php4 and php5 cannot use exceptions. Period. Any php5 script that does not support php4 must use PEAR_Exception for POTENTIALLY fatal errors ONLY (errors that if *unhandled* must terminate the script). This means any error that must leave the context (an error that would result in a return PEAR::raiseError() or die()) Any php5 script that does not support php4 must not use PEAR_Error, but may not use exceptions for ANY errors that can be safely unhandled - this means debug notices, minor warnings, or other informational content. Any non-fatal error must be 1) loggable 2) trackable by the user, and must include a originating package b error code, for easy machine handling c error-specific data (if any) separate from the error message ('database "a" blew up' would include the information that the database was "a") d an error message 3) if possible, re-packageable into a more serious error or exception 1 is possible with trigger_error 2b and 2d are possible with trigger_error, but 2a and 2c are not, unless you do the serialized error object trick. 3 is easy if you use throw in a trigger_error handler, but a bit harder for non-exception errors 1-3 are naturally very easy in PEAR_ErrorStack, since I was thinking about these problems. PEAR_ErrorStack is php5-compliant. My use of "bullshit" was in reference to that misinformation, among other things. there are other solutions too. I've requested on internals that trigger_error be allowed to accept an object similar to the exception object, as this would solve this issue, but of course, was ignored since I didn't provide any code (very common on any list :) 2a is absolutely essential. If you have an application with many different packages, the source of an error is really hard to track without the beautiful context trace that Exception provides. Greg P.S. I am and have been in camp 2 all along. Why? phpDocumentor works in both php4 and php5. php5 support in phpDocumentor is newer, and has a few more bugs than php4 support, but it does work. I'd like to rewrite phpDocumentor for php5 from scratch (and have been working on this), but this will take a REALLY long time, and since the modifications to make the php4 version work in php5 are minor, why should I simply deny php5 users the option of having a documentor?