> First post here; been watching for a while though.

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

[2]  I  would prefer @?. This makes the error-suppression obvious. But
this leads to...

[3]  ...  are we saying that [a] we are still suppressing a deep error
or  [b]  or that an error state does not exist anywhere when you use a
special  operator?  In  other  words,  is  it  now  going  to be fully
supported  to  use  undefined  variables,  as  long  as  we always use
operators  that  take  them  into  account?  This seems to be inviting
criticism  from other language fanboys (if we care) since they already
hold the non-fatal use of undefined variables in contempt.

[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

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

I  haven't  really  thought about the edges, but thought I'd put those
out there.

Cheers,

Sandy


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to