On Mon, Jul 9, 2018 at 9:03 PM Ryan <iggyv...@gmail.com> wrote:
> Hello all! Longtime PHP user, first-time contributor to internals (sorry
> if I screw anything up)!
>
> I'd like to propose either the deprecation (7.next - likely 7.4 at this
> point) and removal (8.0) of the T_LOGICAL_OR (or), T_LOGICAL_AND (and), and
> T_LOGICAL_XOR (xor) tokens, or aliasing them to ||, &&, and !=
> respectively.
>
> The behaviours of the two sets of logical operators are very similar (it's
> incredibly unclear how $x or $y would differ from $x||$y). They perform
> almost identically except for the fact that the former set has a precedence
> lower that the assignment, null coalescing, and ternary operators[1]. The
> page on logical operators[2] states that the reason the two variations
> exist is that they "operate at different precedences" (which isn't a reason
> for existence, but rather a statement of differences).
>
> Example #1 on the logical operators page[2] gives an example of this
> difference:
> $e = false || true; // true
> $f = false or true; // false
>
> Because of the difference of precedence, the second line is evaluated as
> ($f = false) or true;
>
> In my mind (and in the mind of every programmer I've spoken to about this),
> this violates the principle of least astonishment[3]. The assignment
> operator is usually thought to be the lowest level of precedence other than
> parenthesis (as a typical statement would be "do some thing, then assign
> its value to this varible").
>
> This[4] stackoverflow question sheds some light on the intent of the
> alternative operators - they are used for "control flow" in the style of
> Ruby's "unless" operator[5]:
>
> defined("SOME_CONSTANT") or die("SOME_CONSTANT was not defined");
>
> However, this behaviour has nothing to do with the difference of precedence
> - rather this is due to short circuiting.
>
> The only difference between the two (unless there are interactions I'm not
> aware of with the ternary or null coalescing operator) is the precedence
> with the assignment operator, causing the return value to be assigned
> without respect to the conditional. I ran a quick (possibly imperfect)
> script on GitHub's top 30 repositories, and of the usages of the
> T_LOGICAL_* operators all but this one[6] operated equivalently to the
> symbolic ones:
> $gdImage = @imagecreatetruecolor(120, 20) or die('Cannot Initialize new GD
> image stream');
>
> In this case, the result of imagecreatetruecolor is intended to be placed
> in $gdImage, or if it is falsey, die with an error. This could be
> rewritten as:
> ($gdImage = @imagecreatetruecolor(120, 20)) || die('Cannot Initialize new
> GD image stream');
>
> Or, in my opinion, more cleanly:
> $gdImage = @imagecreatetruecolor(120, 20);
> if(!$gdImage) die('Cannot Initialize new GD image stream');
>
That is a matter of style, as I find $a = func() or die more clear that the
version that uses ||
Not chaining stuff together is a third style.
This feels like a Python PEP request. By that I mean that Python wants to
have only one way to do any one task. Perl style is there’s more than one
way to do it.
PHP has been a mix of these styles.
The big question I have is how much PHP code will break due to an enforced
style requirement?
Removing them for style seems like it would be a big BC break. Aliasing
them might lead to more subtle bugs in legacy code.
>
> I've written a very rough draft RFC here[7] - and I would love feedback.
> If it's taken well I can put it up on the wiki.
>
> Thanks,
> Ryan "Iggy" Volz
>
> [1]: http://php.net/manual/en/language.operators.precedence.php
> [2]: http://php.net/manual/en/language.operators.logical.php
> [3]: https://en.wikipedia.org/wiki/Principle_of_least_astonishment
> [4]: https://stackoverflow.com/a/5998351
> [5]:
>
> https://www.tutorialspoint.com/ruby/ruby_if_else.htm#Ruby%20unless%20modifier
> [6]:
>
> https://github.com/PHPOffice/PhpSpreadsheet/blob/aa5b0d0236c907fd8dba0883f3ceb97cc52e46ec/samples/Basic/25_In_memory_image.php#L24
> - likely copied from
> http://php.net/manual/en/function.imagecreatetruecolor.php
> [7]: https://github.com/iggyvolz/Unifying-Operators-RFC
>
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
