Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70425 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89738 invoked from network); 26 Nov 2013 18:35:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Nov 2013 18:35:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=jezzgoodwin@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=jezzgoodwin@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.169 as permitted sender) X-PHP-List-Original-Sender: jezzgoodwin@gmail.com X-Host-Fingerprint: 209.85.214.169 mail-ob0-f169.google.com Received: from [209.85.214.169] ([209.85.214.169:59481] helo=mail-ob0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3E/7A-39355-9E9E4925 for ; Tue, 26 Nov 2013 13:35:22 -0500 Received: by mail-ob0-f169.google.com with SMTP id wm4so6298385obc.0 for ; Tue, 26 Nov 2013 10:35:19 -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 :content-type; bh=CA9u/Rch5BIztYceTimdq3fune1V3NeHm7xaBa93ylY=; b=cdSmU/MVjA9pmRHKJH0rebCulYSeqTcaSHBKFxDo3mwBYbPofwmUDn/Brjaw6Kflor lEk979vR7FCu6ay6YxpHG00LdeGUR/ErenlLjCDmLYxRycu4v8a8jnsZo3oDRNO4fblA UZFJjvgxMsh5rOpSxxjdslEai5xGxIda26SYDDAhO03EdeozBnmTUgGguz50V11NS/1K KPTdCzaPbgqnE6wKbthXcq8Vv99IvyfAQDo1HczNHHwcWUItZKG1ddGfbEctls7klqwM RlMtdMqE14i7NjvEzjRbTJGK5Qf42MHm1ljVl2u/5j7IhcC1sXoAjuR8npQBdGiTyOJB czFA== MIME-Version: 1.0 X-Received: by 10.182.80.196 with SMTP id t4mr30699740obx.1.1385490919023; Tue, 26 Nov 2013 10:35:19 -0800 (PST) Received: by 10.182.167.5 with HTTP; Tue, 26 Nov 2013 10:35:18 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Nov 2013 18:35:18 +0000 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary=047d7b2e4eda116b5704ec18be30 Subject: Re: [PHP-DEV] [Proposal] Modification to ?: functionality From: jezzgoodwin@gmail.com (Jezz Goodwin) --047d7b2e4eda116b5704ec18be30 Content-Type: text/plain; charset=ISO-8859-1 Hi, Before mentioning anything about new syntax, I thought I'd point out that this code is already possible for setting defaults: (isset($foo)) ?: $foo = 'default'; or isset($foo) ?: $foo = 'default'; (I personally prefer wrapping the condition within brackets) Saying that, I do think a syntax for setting defaults which doesn't involve typing the variable name twice would be nice. My favourite one listed so far is: $foo ?= 'default'; -- Jezz On Tue, Nov 26, 2013 at 6:23 PM, Philip Sturgeon wrote: > On Tue, Nov 26, 2013 at 1:08 PM, Etienne Kneuss wrote: > > > > > > > > On Tue, Nov 26, 2013 at 6:57 PM, Philip Sturgeon > > wrote: > >> > >> On Tue, Nov 26, 2013 at 12:41 PM, 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. > >> > > >> > Proposal: $foo = $arr['value'] ?:: ""; > >> > > >> > 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 > >> >> > > >> >> > >> > >> This seems like a cracking time to suggest: > >> > >> $x ||= $y; > >> > >> The difference? Anything left of the ? SHOULD fail if it is not set, > >> because you are using it in a condition which is dangerous and odd for > >> other types of condition, but adding in this new syntax (similar to > >> Ruby) would essentially evaluate to this: > >> > >> > >> empty($x) ? $y : $x; > >> > >> This gives keeps the behavior of ternary operators working in the same > >> way, but adds what we want: the ability to nicely set defaults for > >> variables and array keys that may not be set. > > > > > > To me this reads as $x = $x || $y like all the = binary operators. > So it > > would definitely feel weird to use that syntax for something else... > > > >> > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > > > > > > > > -- > > Etienne Kneuss > > http://www.colder.ch > > It is not $x = $x || $y but $x || $x = $y. > > > http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5488.html > > Ternary is being used by us to set defaults, but it is not the only > use of ternary, so making it totally quieten potential warnings and > errors is a weird use of a ternary. It's one of those "we do it this > way because its all we have" options and going further down the road > of abusing ternaries for this functionality does not make the > situation more simple. > > Currently: > > $foo = isset($foo) && $foo ? $foo : 'default'; > > Proposed change by OP (with BC break): > > $foo = $foo ?: 'default'; > > New ternary suggested by others, with "error suppressing": > > $foo = $foo ??: 'default'; > > People will try using that with all sorts of other operators involved. > What happens when you do $foo = $foo == 'bar' ??: 'default'; It gets > complicated. > > $foo ||= 'default'; > > Pretty obvious what is happening. If foo is falsey it will use > 'default'. We can wrap $foo in isset or empty and make it more > durable, which certainly would take care of the OP's concerns without > breaking the way ternaries currently work - which is not actually > broken just not very handy at setting defaults for non-existent > variables. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --047d7b2e4eda116b5704ec18be30--