Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97354 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6772 invoked from network); 11 Dec 2016 10:29:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Dec 2016 10:29:25 -0000 X-Host-Fingerprint: 87.75.96.78 static-87-75-96-78.vodafonexdsl.co.uk Received: from [87.75.96.78] ([87.75.96.78:2422] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 53/D9-12501-38A2D485 for ; Sun, 11 Dec 2016 05:29:24 -0500 Message-ID: <53.D9.12501.38A2D485@pb1.pair.com> To: internals@lists.php.net References: <3B.50.06670.2F620385@pb1.pair.com> In-Reply-To: Date: Sun, 11 Dec 2016 10:29:18 -0000 Lines: 7 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 X-Posted-By: 87.75.96.78 Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.2 From: TonyMarston@hotmail.com ("Tony Marston") "Nikita Popov" wrote in message news:CAF+90c91SPFOHiTJGpwTEvZt_Wyk+hTX4-TANTMsshhcTQQVfw@mail.gmail.com... > >On Sat, Nov 19, 2016 at 11:18 AM, Tony Marston >wrote: > >> "Nikita Popov" wrote in message news:CAF+90c8Wox0wadAVPsP83er= >> G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com... >> >> >>> Hi internals! >>> >>> I've submitted this RFC for PHP 7.1 previously, but didn't follow >>> through >>> due to time constraints. Now I'd like to propose an extended version for >>> PHP 7.2 and vote on it sooner rather than later to avoid a repeat >>> performance. >>> >>> https://wiki.php.net/rfc/deprecations_php_7_2 >>> >>> The RFC combines a number of deprecation and removal proposals. Each one >>> will get a separate 2/3 majority vote. The RFC overlaps with some >>> recently >>> discussed topics (each, binary strings) -- I'm fine with dropping these >>> if >>> someone has a more specific RFC. >>> >>> I expect some of these are no-brainers, while others are more >>> controversial >>> -- please share your specific concerns. >>> >>> Thanks, >>> Nikita >>> >> >> I am against the removal of the $errorcontext argument of error handler >> as >> this has been a valuable part of my error handler for over ten years. >> Whenever trigger_error() is called with a fatal error I write all >> available >> details to a log file as well as sending an email. In order to obtain >> additional data I use errorcontext to determine the following: >> >> a) Was it called from a function or an object? For this I use code such >> as >> the following: >> >> if (isset($errcontext['this']) AND is_object($errcontext['this'])) { >> >> b) If it was called from an object, was it one of my database objects? If >> yes, then obtain some extra information using code such as the following: >> >> // retrieve error details from DML object >> if (method_exists($errcontext['this'], 'getQuery')) { >> $query = $errcontext['this']->getQuery(); >> } // if >> if (method_exists($errcontext['this'], 'getErrorNo')) { >> $errno = $errcontext['this']->getErrorNo(); >> } // if >> if (method_exists($errcontext['this'], 'getErrorString')) { >> $errstr = $errcontext['this']->getErrorString(); >> } // if >> if (method_exists($errcontext['this'], 'getErrorString2')) { >> $errstr2 = $errcontext['this']->getErrorString2(); >> } // if >> > >I'm afraid you're out of luck here :/ This usage will no longer be possible >as of PHP 7.1 -- independently of the deprecation proposed in this RFC. >See: https://3v4l.org/sQBL9 > >Prior to PHP 7.1 $this was *sometimes* included in the symbol table (to be >more precise, whenever $this was used as a CV, rather than implicit UNUSED >operand). As of PHP 7.1 $this is never included in the symbol table. This >change is due to https://wiki.php.net/rfc/this_var. > >But! This functionality is still available through debug_backtrace(). >That's the correct way of fetching the $this of a parent frame, which >should always work (rather than *sometimes* on PHP < 7.1), and is >independent of the error handling mechanism. The RFC does not specify this, it simply says "use a proper debugger". Will I still be able to use debug_backtrace() to obtain the same information that is available in $errorcontext?If so, this should be explicitly stated in the RFC. >So, to clarify: Is $this the only thing from the error context you're >interested in? Or do you also use all the other variables? I use all the other variables as well, but sometimes I need to use $errorcontext to supply additional information -- Tony Marston