Re: Fix incorrect ternary '?' associativity for 7.0?
| From: | Robert Williams | Date: | Mon, 15 Dec 2014 04:45:36 +0000 |
| Subject: | Re: Fix incorrect ternary '?' associativity for 7.0? | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-79651@lists.php.net to get a copy of this message | ||
Some thoughts from user land…
On the concern of breaking code out there that relies on the current behavior, I strongly suspect
far more code would be *fixed* if the ternary operator were changed to match what other languages
do. I hate to admit it, but my own shop is a good example. We have a particular application that has
thousands of business rules in the form of boolean expressions written using the ternary operator.
When I took over the application, every one of them that was non-trivial (i.e., 95% of them) was
wrong because the developers who wrote them didn’t understand how the operator works. It’s still
a problem. If the operator were fixed in v7 — really fixed, not just made non-associative — all
those rules would magically work; that alone would present a strong impetus for us to migrate that
app.
And the problem isn’t restricted to “those” guys that worked on that application back in the
dark ages. The folks working here now still struggle with ternary if they haven’t used it
recently. They’ve had enough code flagged in reviews to know that it’s problematic, but the
usual solution is to rewrite it with switch or if-else, or to go crazy with parentheses. Either way,
their code won’t break if the operator is fixed.
I’ve also interviewed a lot of PHP developers, and I usually ask about the ternary operator.
Depending on their experience level, my hope is that they either A) know all about it and can use it
without fear, but are respectful of the confusion it can cause others, or B) they don’t really
understand it, but they know it can bite them so that they’re careful if they encounter it or feel
the need to use it. The vast majority of the time, however, I get C) they think they know all about
it and have no fear of using it — but their understanding is completely wrong. This is across the
board, all experience levels from junior guys with a year under their belts to senior guys with 10+
years.
So, it seems that very few PHP developers actually understand how the ternary operator works in PHP.
And those that do, because they tend to rarely use it in nested form, usually either just avoid
doing so even when it makes sense or uses parentheses to avoid having to think too hard. Either way,
their code is probably safe, and even if it’s not, nested use of ternary is so rare in most code
bases that a manual review is not too troublesome.
As for the vast majority of developers who don’t understand the operator: the code everyone here
is so worried about breaking is largely written by these folks, and *it’s already broken*. Fixing
the ternary operator now will only help most of this code, while making it non-associative will
break the code in a different way while also breaking the code of those who do understand the
operator. Fixing it now, or changing it now to fix it later - either way, working code that
doesn’t rely on parentheses needs to be adjusted. Fortunately, the nested ternary is a rare beast
(in most apps, anyway), but even so, most folks would like to do that review only once. And if
it’s to adjust code to work more sanely, the way most other languages do it, well, it stings a lot
less in that case.
So my opinion, as a manager of millions of lines of closed-source code that I know no one else will
fix for me, is to make changes to the ternary operator just once, and make that change one that
fixes it to fit most people’s expectations. That’s the path that would be most beneficial to me.
--
Bob Williams
SVP, Software Development
Newtek Business Services, Inc.
“The Small Business Authority”
http://www.thesba.com/
Notice: This communication, including attachments, may contain information that is confidential. It
constitutes non-public information intended to be conveyed only to the designated recipient(s). If
the reader or recipient of this communication is not the intended recipient, an employee or agent of
the intended recipient who is responsible for delivering it to the intended recipient, or if you
believe that you have received this communication in error, please notify the sender immediately by
return e-mail and promptly delete this e-mail, including attachments without reading or saving them
in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail,
including attachments, is prohibited and may be unlawful. If you have received this email in error,
please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if
any).