Re: How to get a PHP bug fixed?

I don't understand. There already IS the 'args' field where huge objects also can be (and very often are). The new 'object' field does not make any difference in this regard. Dne Sun, 06 Jan 2013 00:42:58 +0100 Stas Malyshev <smalyshev@sugarcrm.com> napsal(a):

Hi!

Are you sure there should be the $options parameter? It would not save any memory because the trace needs to be pregenerated regardless. Back compatibilty clearly doesn't need to be that strict in this case because for example in case of debug_backtrace function the 'object' fields where added in 5.1.1 (not in 5.1.0!) and were enabled by default (there wasn't even a way to disable them - that came with 5.2.5).

Lacking it will mean that the output of this function will be huge and frequently impossible to properly display without filtering, as objects tend to be huge and complex. So you won't be able to do var_export($e->getTrace()) anymore and get something useful. The whole point of having those args in other backtrace function is to make them easily useful in logs, etc. without additional filtering. So yes, I think the parameter would be useful there. Actually, adding it without a parameter may very well break some apps that casually do something like: catch(Exception $e) { $this->log->debug("Caught exception, backtrace: ".var_export($e->getTrace(), true)); } Since the whole trace will be loaded into memory and that may cause out-of-memory condition if the object in question aggregates tons of other objects. Besides that, for consistency reasons it may be useful that all backtrace functions would have the same options. That may mean we'd have to post-process the result of getTrace, but it should not be too hard to do...

With that in mind there is no need for the $options parameter in my opinon. Which meens the only thing missing is the tests, right?

Tests would be good in any case.