Re: Implicit isset/isempty check on short-ternary operator

Sanford Whiteman wrote: > Same here. > > Here's my take: > > [1] I don't like ?? / ? because it is disjunctive with === / ==.. The > extra equals sign strengthens equality comparison, while the extra > question mark essentially _weakens_ the ternary operator (making it > more forgiving). (Sure, a case could be made that an "extra" duplicate > operator has no inherent meaning overall, but these two operators seem > to be in a similar domain.) I disagree. They both reinforce the operator. The = character means equivalence. == means that it is equal, === means that it is very very equal. The ? character means uncertainity, doubt. A single ? in a ternary operator means a question (if() construct). A ?? would not only mean is this true? but also does it even exists? It also looks strange to my code parser (looks like a wtf comment) but I'd probably adapt to that new operator easily. > [4] Strange idea: what about treating the variable as defined after > you test it with the special operator, even if you don't specifically > assign it a value? > > So: > > $varor2 = $var1 @?: 2 // $varor2==2, no warning because special > ternary is used > > $varor3 = $var1 ?: 3 // $varor3=3, but no warning because $var1 has > been implicitly defined in special expression This looks like a source for all kind of side-effects to me. I'm not even convinced that testing for raw variables would be useful. I think the usecase is for testing arrays. > [5] Sort of the opposite of [4] and continuing the question of [3], > what about only letting a variable be special-op-checked once before > throwing a warning. So you can suppress (or not throw) the undefined > warning once, but it is assumed that you will define the variable in > that statement. So this would discourage the continuous use of the > same undef var throughout code (which seems like a code smell), while > allowing for the real case that you're using the special-op to filter > $_REQUEST or whatever -- one time. Tests shouldn't have side effects. Allowing the special-op one time, means that the addition of a check in one place will start spewing in a completely different place of the codebase. The way of forcing the users to set the undefined variable in one check is not keeping a track if they have used a magic operation to check it and didn't set it after that, but defining a set-value-if-unset operator. A syntax like ?= looks like a set-if-set, so perhaps it would be more appropiate using !?= > I haven't really thought about the edges, but thought I'd put those > out there. Thanks for sharing!