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 <smalys...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
