Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64578
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.48 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Stas Malyshev" <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <CACYoSNCr30Fg+oBASGmLYLk+ziXQy990mvZbLNUe8viNhZTdxQ@mail.gmail.com> <50E742A7.9010909@sugarcrm.com> <op.wqglnxjnqezz7x@jachym-pc> <50E8A99F.5000900@sugarcrm.com> <op.wqgotfcfqezz7x@jachym-pc> <50E8BA82.5000700@sugarcrm.com>
Date: Sun, 06 Jan 2013 00:47:20 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.wqgpo6idqezz7x@jachym-pc>
In-Reply-To: <50E8BA82.5000700@sugarcrm.com>
User-Agent: Opera Mail/12.11 (Win32)
Subject: Re: [PHP-DEV] How to get a PHP bug fixed?
From: enumag@gmail.com (=?utf-8?B?SsOhY2h5bSBUb3XFoWVr?=)

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.