Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105837 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 5729 invoked from network); 4 Jun 2019 01:41:49 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 4 Jun 2019 01:41:49 -0000 To: internals@lists.php.net References: Date: Mon, 3 Jun 2019 23:52:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 94.1.167.52 Subject: Re: PHP RFC: Nullsafe Calls From: markyr@gmail.com (Mark Randall) Message-ID: On 03/06/2019 09:28, Jean-Baptiste DELHOMMEAU wrote: > I would like to awaken the discussion around the RFC Nullsage Calls : > https://wiki.php.net/rfc/nullsafe_calls Personally, I have my suspicions that PHP is starting to expose itself to operator fatigue. There have been quite a few suggestions made over the last couple of years that want to add new operators that would just serve as syntax sugar for a niche problem (for example, chaining) but serve to make things more convoluted than they need to be. That said, let me now proceed to be a massive hypocrite and propose a new operator, because IMO we should be looking to gain the most general benefit out of the operators that are added. Let's try and find a wider solution, for example, right now if you try to chain things that hit a null, an Error object is thrown... so maybe we could use that. There's also been lots of calls for more built-in functions to throw exceptions rather than writing notices and errors, and so the use of try / catch would become more prominent with that as well. But... a 5 line try/catch block can be a pain, so maybe we could create a shorthand that would return a particular value whenever an exception was thrown? Instead of ... try { $result = $x->y()->z(); } catch (Error $ex) { $result = null; } $result = attempt $x->y()->z(), Error => null; (I couldn't immediately think of a way of modifying 'try' that wouldn't mess the parser if opening curly braces weren't used). Derive a new NullObjectError from Error, throw it in the relevant spot, and you've now got a way of handling things where you can specify your own value. $result = attempt $x->y()->z(), NullObjectError => null; Out of it we would get a shorthand way of handling large numbers of future throws and "restore" their error-condition-by-return-value behaviour where you're more concerned that it failed, than with the actual error message. return attempt database_query('...'), DatabaseException => null; I know this is a huge tangent, I just wanted to throw it out there as a possible option for handling chaining, that would potentially kill many more birds down the road in the process. -- Mark Randall