Re: PEAR Coding Standards

I'm afraid I won't have time to write a detailed response to this for a while, the concerts are flying thick and fast. I think that the best I can offer right now is that there is no way to fix the problems in PEAR_Error without breaking BC. The problems of simply "upgrading" the existing PEAR_Error are far too much. Error_Raise/Error_Handler *was* an upgraded PEAR_Error. 80% of the users - including you - immediately disliked it. Come Error_Stack/PEAR_ErrorStack, and there were no major criticisms from anyone. Perhaps no one studied it. I'm willing to fix any major design flaws. However questions like this one

     blazingly fast - blows PEAR_Error out of the water
     ** why - shouldnt we sort this out for PEAR_Error

and this one

     Package-specific errors
     ** you can do this by creating Package Error Objects, that wrap
     PEAR_Error

Show that you haven't actually tried doing this with large projects. PEAR_Error has been around for years and years, and there are a few projects that do this. However, not all of them do, so it is totally impossible to determine the source of an error. Unless you know the source of an error, you have to regulate error code integers, which is a complete disaster for any project developed in a large umbrella. I could go on for a while, but I've said all of the arguments before many times. If you want to know what the problems are, talk to any coders on just about any php message forum. Or read the pear-dev archives. I'm happy to have some outside source do an unbiased comparison - I've offered many times to change anything that doesn't quite work. The project is alpha for a reason. Greg Alan Knowles wrote:

It would be nice if the introduction to PEAR_ErrorStack made a fair and level comparison, I've not had time to judge in detail the pro/cons of PEAR_Error vs PEAR_ErrorStack. This is the current introduction from the manual, and at present, doesnt help explain why it should be considered over PEAR_Error.. *

     Fully unit-tested and documented
     ** is this really a selling point - isnt all of pear supposed to
     be like this????

Incidentally, yes, this is a selling point. If unit testing and documentation were actual requirements, more than 2/3 of PEAR would simply disappear :)

*

     blazingly fast - blows PEAR_Error out of the water
     ** why - shouldnt we sort this out for PEAR_Error

*

     Package-specific errors
     ** you can do this by creating Package Error Objects, that wrap
     PEAR_Error

*

     Error levels (notice/warning/error/exception)
     ** This may be a selling point, although it could be done kludgly
     with $userinfo in PEAR_ERROR..

*

     Error context data is saved separate from error message
     ** not sure what the benifit of this is.

Error messages like "file /home/stuff/info data cannot save" written by developers can be rephrased if you know "/home/stuff/info" is the file name. It also simplifies translation, as you can plug the filename in the right place for non-standard grammars.

*

     Error cascading - parent errors can be specified
     ** not sure what the benifit of this is.

displaying errors in a CMS - the user only sees top-level errors, administrators can see both top-level and low-level, and know the connection.

*

     Dynamic error message generation allows generation of multiple and
     distinct error messages from the same error object
     ** not sure what the benifit of this is. = does this hint at
     translations? - in which case its supported by Package Error
     Objects, that wrap PEAR_Error

Not just translations.

*

     Sophisticated callbacks are available for error message
     generation, error context generation, and error handling
     functionality, ...
     ** not sure what the benifit of this is.

Have you ever used PEAR::setErrorHandling()? Or read the manual for PEAR_ErrorStack's callbacks? It's all in there.