Re: Re: using PEAR_ErrorStack for debug output
| From: | Joshua Eichorn | Date: | Mon, 14 Jun 2004 03:15:03 +0000 |
| Subject: | Re: Re: using PEAR_ErrorStack for debug output | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-30619@lists.php.net to get a copy of this message | ||
Philippe Jausions wrote:
greg@chiaraquartet.net wrote:-joshPhilippe says: Agreed, don't we all have our little solution for debug output ;-) What I was saying is if you are using an image template engine and want to debug, your debug message may end up in the binary string of the image. Sure you'll get a broken image, but not convenient for debug, hence the proposed use of the PEAR::Log as an alternative... I think accepting the log object as $option['debug'] is the best approach because doesn't actually limit user to PEAR::Log but to any class as long as it has a "log()" method... -Philippe Greg says: PEAR_ErrorStack is designed specifically for this purpose $stack->push([debug level], 'debug', array([debug info]), 'debug message'); can be used. The user can set the log object externally, if the stack is a singleton, and you don't even need to write it into the Template class. ErrorStack is somewhat misleading. The primary reason it expects a string for the error level is to allow for some custom stuff such as passing in debug information. Obviously, you'll only want to do this if the debug level is high enough to justify displaying, for performance reasons, but that is another issue. GregI will definitely look into that. At least we were going out of the "dumb" echo() ;-) Any plan for ErrorStack to get out of alpha stage? Development of PEAR::Template seems to come along not too bad so it would be a "pain" to adapt to a moving target if ErrorStacks's API is not set yet. -Philippe Greg is traveling until July 4th so it might be hit or miss getting a reply from him. From his emails and ealier discussions i belive ErrorStack is going to be remaining in alpha until people start using it and actually make sure the api doesn't suck. So i don't think there should be much pain if you start using it now, the only changes are going to be the ones you guys (and anyone else using it) suggest.