Re: Re: PEAR_Exception in CVS

Hans_l wrote:

This is PHP5 only. I think that's the way to go because nothing PHP4 is gonna run in E_STRICT, hence no PHP5 PEAR package can work with any PHP4-friendly libraries.

Apologies in advance for the long message, I would like to explain a basic difference viewpoint that I feel will get in the way of development if it isn't worked out. Summary: we should require complete E_STRICT compliance except for php5 keywords for php4 packages that will work in php4 and php5, but there must be a transition between php4 and php5, based on API compliance. Long version: I think you're approaching this from a backwards perspective of how I see that things will happen. There is a HUGE base of PHP4-based applications, and many of them work really well. Even if you or I disagree with the masses about the quality, there are lots of people who use these pear script things in custom scripts based on the current PEAR API. I don't know about you, but I don't imagine that everyone will be as zealous about rewriting their scripts simply because the syntax for error handling has changed. We need a time period that allows packages that work in both PHP4 and PHP5. E_ALL would be the standard for these packages, so that complex applications can easily move to php5 after everything has been fully tested. The best thing about Tomas's script (and better than PEAR_ErrorStack alone) is that PEAR::raiseError will still work - the API is the same for both PHP4 and PHP5. There was no facility for doing warnings/notices in PEAR, and so PEAR_ErrorStack does not break API. PEAR_ErrorStack is php5-compatible, even if it isn't E_STRICT. Perhaps I could provide a version with all "var" replaced with "protected" and then it would :). There will be other more significant changes in the move to php5, and we should limit the number of changes that users must process at one time to aid in debugging. Don't forget that people are not going to jump to php5 simply because a few geeks like me say it's great :). It must be proven to be great, and complex packages/applications like DB will not transition to php5 overnight, there will be a period where php4 will still be supported. Some of the application will only need to be modified rather than redesigned to work in PHP5, but what if the similarities between PHP4 and PHP5 could be used to make this transition smooth? Why require a complete rewrite of a simple application, when in most cases, changing a few "var" statements to "public" or "private" is all that will be needed to comply with E_STRICT? Once the transition occurs, and php4-ites run their applications in php5, php5-only scripts may be released with impunity. For this reason, if we can encapsulate the php5-specific error stuff (exceptions) and provide an API to error handling that both php4 and php5 packages/applications can use, it will be far more intelligent. Any other method will simply force a serious stability downgrade for months. Or worse, a "stable" package that has hidden bugs. sure, php5-only packages need to be E_STRICT to help make E_STRICT possible, but end-user applications need not be E_STRICT until they have had the time to run under php5 and understand both the problems and benefits. Greg