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).
