Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102682
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.67 as permitted sender)
MIME-Version: 1.0
References: <CAD2kNXBHTo5pJv3sYfEZjgCE6t8Nshv8=VoAesb+eamDhUVRpQ@mail.gmail.com>
In-Reply-To: <CAD2kNXBHTo5pJv3sYfEZjgCE6t8Nshv8=VoAesb+eamDhUVRpQ@mail.gmail.com>
Date: Tue, 10 Jul 2018 00:26:32 -0600
Message-ID: <CAMPTd_C0YX2hrinfJ0_AWj8z-z4qzh-47rD95=39SpH=f=PH8w@mail.gmail.com>
To: Ryan <iggyvolz@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000b4b50b05709f363a"
Subject: Re: [PHP-DEV] Unifying logical operators
From: walterp@gmail.com (Walter Parker)

--000000000000b4b50b05709f363a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 9, 2018 at 9:03 PM Ryan <iggyvolz@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), a=
nd
> T_LOGICAL_XOR (xor) tokens, or aliasing them to ||, &&, and !=3D
> 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 preceden=
ce
> lower that the assignment, null coalescing, and ternary operators[1].  Th=
e
> page on logical operators[2] states that the reason the two variations
> exist is that they "operate at different precedences" (which isn't a reas=
on
> for existence, but rather a statement of differences).
>
> Example #1 on the logical operators page[2] gives an example of this
> difference:
> $e =3D false || true; // true
> $f =3D false or true; // false
>
> Because of the difference of precedence, the second line is evaluated as
> ($f =3D 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 th=
an
> 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 preceden=
ce
> - rather this is due to short circuiting.
>
> The only difference between the two (unless there are interactions I'm no=
t
> 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 =3D @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 =3D @imagecreatetruecolor(120, 20)) || die('Cannot Initialize n=
ew
> GD image stream');
>
> Or, in my opinion, more cleanly:
> $gdImage =3D @imagecreatetruecolor(120, 20);
> if(!$gdImage) die('Cannot Initialize new GD image stream');
>

That is a matter of style, as I find $a =3D func() or die more clear that t=
he
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=E2=80=99s more th=
an 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%20modi=
fier
> [6]:
>
> https://github.com/PHPOffice/PhpSpreadsheet/blob/aa5b0d0236c907fd8dba0883=
f3ceb97cc52e46ec/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
>
--=20
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandei=
s

--000000000000b4b50b05709f363a--