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

Hans Lellelid wrote:

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

This is enough of a controversial point to merit a voting. I set next wednesday as the date I'll start outlining the resulting discussion in the wiki into the pear error handling guidelines. I think this could be done in two phases. First, we'll try and aprove in pepr the consentual part of the text, leaving alternatives for the controversial stuff. Then, we'll open votes on these types of points. I really don't have a rigid position on error silencing. While I personally consider it bad practice, I understand the point made by Lukas that mandatory error handling hampers quick'n'dirty script writing. PHP has been successfull thus far using less than ideal development methodologies, so I'd like to hear how people out there are using the language, and whether it's THAT bad using just regular exceptions. The point can be made that if error silencing were that important, then it would be a possibility for the default handling of uncaught exceptions, built into PHP. However, we can also presume this was a design fault in PHP5, and therefore needs patchwork by PEAR. Any PEAR solution will look like patchwork, since we can't change PHP's behaviour on uncaught exceptions. But, then again, I feel this is a discussion that can be postponed, lest we get tangled in religious banter. Cheers, -- Sérgio Carvalho AIM: SergioSGC / ICQ: 67512780

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc