Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70419 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76525 invoked from network); 26 Nov 2013 17:57:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Nov 2013 17:57:36 -0000 Authentication-Results: pb1.pair.com smtp.mail=dragoonis@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=dragoonis@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.52 as permitted sender) X-PHP-List-Original-Sender: dragoonis@gmail.com X-Host-Fingerprint: 209.85.216.52 mail-qa0-f52.google.com Received: from [209.85.216.52] ([209.85.216.52:51177] helo=mail-qa0-f52.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FB/A7-39355-011E4925 for ; Tue, 26 Nov 2013 12:57:36 -0500 Received: by mail-qa0-f52.google.com with SMTP id k4so8002539qaq.11 for ; Tue, 26 Nov 2013 09:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JxNCGZA5s8OSdqIl9Y737y0GLvve6RsT6YhYcb/fJf0=; b=yYBDraZJ9ekZ99BpnJNGoK9SPfvJkgdA/fSE9VMz1nyTwPbcbYLDHB/fOR++QGIOKZ K0cht3K+wce/xcbZtAvBop5IVWAjD6FIWk21S9Jfi2RbGnAP65roi0k8dsk9kGTZ/8sp EZUI8DxRhscLkiCkPfw0+52WLnrfElbrX8HOrlpNFAARjfd7olMj1NCmpG3qbnvZKGuO 0EIWGyegHhHcAYtu/lCoVOfKkgMsuKu2N3oyzozl08h/6iQ8YFFta5jWpfuSXCpxRNmg /LVLktWIWwGQsg3Ey+SWRZ56heRa4gojBAL3oZgy0g/gYOcUIPZL8b1mQKOokwsTfmxO o9Jg== MIME-Version: 1.0 X-Received: by 10.49.98.100 with SMTP id eh4mr58556619qeb.42.1385488654086; Tue, 26 Nov 2013 09:57:34 -0800 (PST) Received: by 10.229.233.198 with HTTP; Tue, 26 Nov 2013 09:57:34 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Nov 2013 17:57:34 +0000 Message-ID: To: Etienne Kneuss Cc: Chris London , Mats Lindh , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=047d7bdc9574113a1904ec1837ef Subject: Re: [PHP-DEV] [Proposal] Modification to ?: functionality From: dragoonis@gmail.com (Paul Dragoonis) --047d7bdc9574113a1904ec1837ef Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 26, 2013 at 5:54 PM, Etienne Kneuss wrote: > > > > On Tue, Nov 26, 2013 at 6:48 PM, Chris London wrote: > >> On Tue, Nov 26, 2013 at 10:41 AM, Paul Dragoonis > >wrote: >> >> > >> > >> > >> > On Tue, Nov 26, 2013 at 4:58 PM, Chris London >> wrote: >> > >> >> On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh >> wrote: >> >> >> >> > On Tue, Nov 26, 2013 at 3:43 PM, Chris London >> >> wrote: >> >> > >> >> >> I believe these two statements are functionally equivalent: >> >> >> >> >> >> $foo = $foo ? $foo : 'default'; >> >> >> >> >> >> $foo = $foo ?: 'default'; >> >> >> >> >> > >> >> > They are. >> >> > >> >> > >> >> > I would like to change it so it also checks for isset() so I propose >> the >> >> >> following would be functionally equivalent: >> >> >> >> >> >> $foo = isset($foo) && $foo ? $foo : 'default'; >> >> >> >> >> >> $foo = $foo ?: 'default'; >> >> >> >> >> >> > >> > We can't change the behaviour of ?: that ship has already sailed, we'll >> > just be hurting existing codebases on upgrading and more user education >> is >> > required to understand non-visual changes in syntax like this, lets try >> to >> > learn from our mistakes by not changing 'behaviour' anymore. >> > >> > An alternative syntax that is similar and not ugly would be good since >> the >> > ?: behaviour was broken from the start since you still need to run >> isset() >> > before running ?: which was the problem we tried to solve in the first >> > place but it just didn't happen. >> > >> > I don't like the @ symbol it's too different from what's already there >> on >> > the ternary logic. >> > >> >> My reason for the @ symbol was that it's already used to suppress errors >> so >> to me it seems like it could be interpreted as a suppressed ternary but >> I'm >> open to other suggestions. >> >> >> > >> > Proposal: $foo = $arr['value'] ?:: ""; >> > >> >> I'd be fine with this choice. >> > > I don't see any value in adding yet another operator for this, we already > support this through: > > $foo = @$arr['value'] ?: ""; > Constant intentional error suppression isn't really what we need since the error still happens it just doesn't go through logging and such, whereas from my limited understanding isset() will not trigger any errors to happen at all, so there is a difference here for sure. > > >> >> >> > >> > Thoughts? >> > >> > > >> >> > The would break the assumption that a reference to an uninitialized >> >> value >> >> > would generate a notice, unless explicitly handled in the logic. >> >> > >> >> > While I also would like to have something similar to ?: to handle >> >> default >> >> > values for array keys, etc., this would change a fundamental >> assumption >> >> > that as been in place for many years now. I'm not sure if that's a BC >> >> break >> >> > that would be acceptable this late. An alternative operator may be >> more >> >> > suitable. >> >> > >> >> >> >> What do you think about using: >> >> >> >> $foo = $foo @: 'default'; >> >> >> >> and possibly >> >> >> >> $foo @= 'default'; >> >> >> >> >> >> >> >> > >> >> > The change proposed has also been discussed several times since the >> >> > implementation of ?:. See the ifsetor-RFC: >> >> > >> >> > https://wiki.php.net/rfc/ifsetor >> >> > >> >> > It also contains links to the discussion around the feature back >> then. >> >> > >> >> > --mats >> >> > >> >> >> > >> > >> > > > > -- > Etienne Kneuss > http://www.colder.ch > --047d7bdc9574113a1904ec1837ef--