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

On Mon, 12 Jul 2004 20:01:50 -0400, Hans Lellelid <hans@velum.net> wrote: > 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. How will this not work with non-PEAR components. The only thing I can possibly see is that non-PEAR packages won't have the (same) error silencing capability. The PEAR code will still throw exceptions, the same as any other piece of code, unless the developer chooses to make some of the exceptions warnings. > > 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. Not sure what this has ot do with Exceptions, but I'm for it, it makes sense. > > 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. Again, it's not proprietary. PEAR packages will still throw exceptions, just like any other package, unless the *user* decides to change them into warnings. Thrown exceptions will still be thrown exceptions, period. People don't have to do extra special catch blocks, the same catch(Exception $e) will work for PEAR and non-PEAR packages, no difference except for one extra call on the stack. > > 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. > It's still within PHP5, it's even based on "PHP5's built-in error handling", it's just an optional feature that you don't have to use and are by no means forced to use (except where you would have to use the PEAR_Exception::throw). Perhaps this could be a per-package thing so that some package would allow users to downgrade their errors, but this leads to inconsistencies. We should do it the same everywhere. Now that I've played devil's advocate, I'd like to say that I'm not actually decided on this issue. I like the elegance and simplicity of just throw new PEAR_Exception, but I don't see any problem with an extra call that would increase flexibility and leave those who don't want to use it alone, apart from making them use the extra call. -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--