Vision of PEAR interop (was Re: PEAR_Warning proof of concept)

Justin Patrin wrote:

I'm not sure why you're so against this. PEAR wouldn't be inventing its own exception system, it would be merely adding to it. We're already doing this with PEAR_Exception. Adding a wrapper for throw is not reinventing, it's adding a feature. Yes, the backtrace is one layer deeper and I agree that it skews things a bit and may be hard to handle (if you, say, programmatically check the backtrace...although I'm not sure why you would need to), but adding flexibility is a good thing.

I did some more thinking about this. In particular, asking myself why I am so against it. I have a more complete answer for you :) Really the main reason I'm against this is because I see this as a change that will prevent PEAR packages from being useful with other packages. I see this as the single biggest weakness with the code in PEAR (not talking about organization or politics here). PEAR is a very all-or-nothing, inbred framework because it has made decisions that limit interoperability with non-PEAR PHP code. There is a *lot* of non-PEAR PHP code out there, but to make use of PEAR libraries you must either implement kludgy wrappers or adhere to PEAR standards. With PHP4 the biggest component of this was, of course, error handling. I think in PHP4 PEAR_Error was probably among the best solutions out there, so I'm not really criticizing the solution but I am criticizing this tendency to write exclusionary code. PHP5 has the potential to make PEAR truly successful. What I mean by successful is the ability for people to include individual PEAR libraries in their applications without being forced to do things the "PEAR way". Originally this was exactly the same reason why I argued agains a mandatory PEAR_Exception base class. The fact is, though, that a base class doesn't really affect external code. A non-PEAR package will just as surely catch a PEAR_Exception as an Exception. When you start implementing wrappers for the language constructs with goals of allowing exception handling to be disabled, you are suggesting a very PEAR-exclusive feature. This feature will not only not work when you start building with non-PEAR components, but it will cause a lot of confusion. Besides providing error handling built in to the language, PHP5 also provides interfaces which have the potential to allow a much looser coupling of PEAR packages. For example instead of writing renderers for the various template engines in PEAR, there could be a generic ITemplate that outlined a basic subset of the functionality provided by the various engines. Classes that had template renderers could simply use the ITemplate interface; this would allow me to create my own template very simply and use it instead. Things like that would make PEAR packages much more widely applicable. In short, I have a vision where PEAR can interoperate with non-PEAR packages. I think that to be a successful project the packages need to be loosely coupled. Implementing proprietary error-handling systems goes directly against this. Of course, I also still feel very strongly that this particular need -- to allow disabling of error handling -- is completely bogus, but reason why I am rather over-reacting to it is that I really think that there's a huge advantage to staying within the parameters of PHP5 functionality. Hans