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.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
