Re: [RFC] Implicit isset() in Shorthand Ternary Operator

From: Date: Mon, 08 Sep 2014 13:58:17 +0000
Subject: Re: [RFC] Implicit isset() in Shorthand Ternary Operator
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-77103@lists.php.net to get a copy of this message
On 8 Sep 2014, at 09:06, Michael Wallner <mike@php.net> wrote: > On 07/09/14 14:25, Andrea Faulds wrote: >> >> On 7 Sep 2014, at 13:22, Sherif Ramadan <theanomaly.is@gmail.com> >> wrote: >> >>> I've played around with this branch for a bit and seems reasonable, >>> passes the tests, and doesn't seem to have any serious >>> issues/memories leaks AFAICT. >> >> There’s actually a quite serious issue just now, which is that it >> evaluates the first operand twice if it’s not empty. This is because >> $a ?: $b is expanded to empty($a) ? $b : $a, such that if you did >> something which mutates state in there, it’d happen twice. This is >> obviously not good, and I’m going to figure out how to fix this. >> > > This could very well be the reason why it is like it is today. I doubt it, it’s possible to avoid double-evalution, and I don’t think it’s terribly difficult. I just did things the easy way and it turns out that has problems. On 8 Sep 2014, at 13:04, Shashank Kumar <shashankkumar.me@gmail.com> wrote: > Rather than giving a new meaning to an old operator why not have a different operator for this? > .NET has a 'null coalescing' operator for the same purpose which works out quite well > in the given situation > and is non-ambiguous as well. > http://msdn.microsoft.com/en-us/library/ms173224.aspx We could add such an operator, perhaps with the ?? syntax. However, I don’t really like the idea. It’s too similar to ?: so I don’t think it’d be accepted, and even if it was, I’m not sure we really need another operator. I’d much rather just make ?: do what, IMO, is the right thing and what it always should have done. On 8 Sep 2014, at 08:58, Simon Schick <simonsimcity@gmail.com> wrote: > I feel more like Sherif Ramadan. Even so I've quite often been in the same situation, I > don't think it's a good solution to change something like that, just for the > shorthand-operator. > > I think, the notice is really valuable when accessing the value and doing something with it - > like myFunction($_GET['not_set']), but if you're just checking for the existence, I, > too, think it is more annoying. My way was to suppress it by adding the silence-operator ;) > > I always used like: > @$_GET['mykey'] ?: ”” The silence operator is bad for three reasons. First, it’s very slow, having a significant performance impact. Second, @ silences not only innocuous E_NOTICEs, but *all* errors, even very serious ones. That’s not good. The third is that it interacts with some error handlers badly, or so I’ve heard. > I can't come up with a good mid-way right now, but I don't think it's a good way > to change this ONLY for the short-hand operator. Actually, there is a case for doing it for $a ?: $b and not $a ? $a : $b, in that it could avoid double evaluation (you’d be able to do foo()[0] ?: $bar and foo() would only be called once) and because with the full-length ternary operator, it wouldn’t really help you much: $_GET[‘foo’] ? $_GET[‘foo’] : ‘blah’ isn’t much shorter than the version with explicit isset. -- Andrea Faulds http://ajf.me/

« previous php.internals (#77103) next »