Re: separation of php4 from php5

Hi Greg, This all sounds very dramatic!

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.

I'd like to provide room for a grey area here, which is where I fall. I'll call this the "me me me" perspective. I want to make PHP5-only classes, because I want classes that will throw Exceptions and fit in with my other work, which is PHP5-only from now on. I don't care about PHP4 packages that work in PHP5 or even PHP5 packages that use transition code to be compatible with PHP4. As far as I'm concerned those types of packages are equally valid for other users. I don't know why there has to be a either-or split, but if you think there does -- then option (1) sounds pretty good to me :) To clarify, it was Lukas who articulated what quickly became the "official" PEAR decision that PHP5-only packages need to be E_STRICT. Certainly it makes sense, but also precludes PHP5 packages that will work in PHP4 at all. Since PHP5 packages may not rely on any PHP4 packages, the sentiment seems to be that they should therefore not have any legacy error-handling requirements just for the sake of tradition or be required to use limiting transition code (not talking about ErrorStack) when clearly they are not transition packages.

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())

Can you clarify this? Particularly the bit about what "errors that if *unhandled* must terminate the script". This doesn't make sense to me; classes should throw exceptions for any error that is meant to be handled. All errors are meant to be handled! Asking a class to decide "but should the app really die?" is not appropriate here. The idea with throwing exceptions is that the throwing code *does not know* how serious the error is. It's up to the catching code to make that judgement call.

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

Yes, this sure looks right to me. Why not just settle on a stack-based approach for handling these warnings? I think everyone would like this. Of course, not every package cares about these, so there shouldn't be a requirement that packages have to use ErrorStack (or anything) for warnings. It seems like the way it is currently works quite well -- no getWarnings() methods need to be added to classes. Any package that cared about warnings could call PEAR_ErrorStack::staticGetWarnings($packagename) to fetch the desired warnings. (Perhaps it should be called PEAR_WarningStack, though.) I think you have taken personally some discussion of PEAR_ErrorStack that was never intended as criticism of the package. I would like to see PHP5-only packages take advantage (or more precisely, be *aloweed* to take advantage) of PHP5 features, and I don't see the advantage of using a stack-based error handling solution in addition to throwing Exceptions, that's all. In the Exception model I can create Exception subclasses that have very different signatures, e.g. to handle nesting or composite Exception classes as Justin & I were discussing, etc. Like you said ErrorStack has little to do with whether errors are returned or thrown. I think what I, and perhaps others, were responding to was not ErrorStack per-se, but the suggestion of an ErrorStack-based compromise/transition solution where raiseError() would either throw or return depending on current error handling model.

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?

I think everyone agrees that PHP4 applications should be made to work with PHP5. From the beginning the packages that have fueled these dabases are new, PHP5-only packages. Developers want to be able to use Exceptions in PHP5-only packages. PEAR (via Lukas) has indicated that PHP5 packages must be E_STRICT. The rest sort of fell into (out of?) place from there. Hans