Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102740
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.208.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEUnE0eH2-Lkpnm9YyQERhGUVaEsBa-RDP8zuSkvNgL360Cr9g@mail.gmail.com>
References: <CAD2kNXBHTo5pJv3sYfEZjgCE6t8Nshv8=VoAesb+eamDhUVRpQ@mail.gmail.com>
 <CAEUnE0eH2-Lkpnm9YyQERhGUVaEsBa-RDP8zuSkvNgL360Cr9g@mail.gmail.com>
Date: Tue, 10 Jul 2018 22:20:16 -0400
Message-ID: <CAD2kNXBJSRTERURY5opb_r__KGWfmhXnfmb0HpaGfkA0_+bjZw@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003289990570afe331"
Subject: Re: [PHP-DEV] Unifying logical operators
From: iggyvolz@gmail.com (Ryan)

--0000000000003289990570afe331
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 10, 2018 at 2:26 AM, Walter Parker <walterp@gmail.com> wrote:

>
> That is a matter of style, as I find $a =3D 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=E2=80=99s 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 enforce=
d
> style requirement?.
>

As I said in the OP, out of the top 30 GitHub repositories (the first page
on the API since I couldn't figure out how to get to the second), there was
only one line that would require a change (and it was copy-pasted from the
manual).  Obviously there's no way to truly know how many times it's used
in non-public code, but I'll expand my GitHub search and report back some
more solid metrics.

Removing them for style seems like it would be a big BC break. Aliasing
> them might lead to more subtle bugs in legacy code.
>

PHP 7 code should never be blindly upgraded to PHP 8 (which is what this
would target for actual changes, not just deprecation/notices).  This would
have to be clearly stated in the upgrade guide.


On Tue, Jul 10, 2018 at 5:01 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:
>
>
> As your own next example demonstrates, it does rely on the difference in
> precedence, because without it, you could only use this idiom after
> carefully checking that the left-hand side would be evaluated in one go,
> and probably using an extra set of parentheses.
>

The defined or die idiom does not depend on precedence, because it doesn't
contain an assignment operator.  One could theoretically do
$isDefined=3Ddefined("X") or die() - however that would be pointless as
$isDefined would always be true.


> > ($gdImage =3D @imagecreatetruecolor(120, 20)) || die('Cannot Initialize
> new GD image stream');
>
> This is less readable both because of the extra parentheses, and because
> the || operator is not as easily read as the English word "or".
>

The readability issue is why I included the option to alias to or.  I
definitely agree that x() or die() looks better than x()||die().


>
> While I've not seen it used much in PHP code, the "do this or die" idiom
> is common in Perl (which also has post-fix "if" and "unless" modifiers, s=
o
> those are a different feature again).
>

Forgive my lack of knowledge with perl, but it looks[1] like they only
support a postfix if and postfix unless operators - which can serve the
same purpose as PHP's and/or (x and y =3D> y if x, x or y =3D> y unless !x)=
.
However, I'm not aware of any language that uses and/or for this
behaviour.  I doubt there will be sufficient cause for confusion with perl
as many languages have slightly different behaviours for and/or (and
whether they use the text or symbolic versions).  Lua and python use
and/or, but don't convert the result to boolean and C{,#,++} use symbolic
and convert the result to boolean.  I don't know of a language that uses
and/or in this way (unless I'm wrong about Perl) to denote a postfix
operator.


>
> IF there is sufficient harm in having the extra operators, I would say
> removal is the only option - making them behave as aliases for || etc wou=
ld
> just lead to even more confusion when they *don't* work the same way as i=
n
> Perl, and in earlier versions of PHP. I'm not 100% convinced by the harm,
> though.
>

My thought for aliasing is that it may help with legacy code (if you're not
relying on the return value, which is 99% of cases), as well as there being
no symbolic equivalent for xor (as you state below it's not equivalent to
!=3D as I thought)


>
>
> Finally, a note on the "xor" operator - your draft says that this is
> equivalent to "!=3D", but that is not the case, because both can operate =
on
> non-boolean values. Consider "1 !=3D 2" (true) vs "1 xor 2" (false). I do=
n't
> think I've ever had a use for logical xor in PHP code, but there isn't
> anything to confuse it with, so no reason to remove it.
>

Ah, my mistake.  My only experience with xor was one class that I sat in on
in the middle of the semester.  It may be worth adding a symbolic
representation of xor regardless.




On Tue, Jul 10, 2018 at 2:37 PM, Kalle Sommer Nielsen <kalle@php.net> wrote=
:

>
> I personally wanted to extend this syntax but I never got around to it
> to support: "do() or throw new Exception(...);", tho its just a code
> style over: "if(!do()){ throw new Exception(...); }"
>

do() or throw doesn't actually work because throw is a language construct,
not a function.
$ php -r 'false or throw new Exception();'
PHP Parse error:  syntax error, unexpected 'throw' (T_THROW) in Command
line code on line 1

I actually ran into this at work today writing a bootstrap function.  I had
a function that would return a class that would either give the path to a
file in a subdirectory, or null if it didn't exist.  I was attempting to
call it like $file=3Dself::findFile("subdirectory") and return $file;
(continuing the loop if it didn't return).  However, this isn't possible
since return is a language construct.

[1]: http://perl101.org/flow-control.html


On Tue, Jul 10, 2018 at 2:58 PM, Andrey Andreev <narf@devilix.net> wrote:

> isset($foo) OR $foo =3D 'bar'; (and similar variations using empty()
> and/or &&) is another pattern I use often to set fallback values for
> empty or missing inputs.
>
> An eventual deprecation would make literally all of my code output
> entire screens of warnings.
>

$foo=3D$foo??"bar"; would work there.  I could definitely see this being an
issue if you weren't using isset (although a concrete example of that
doesn't come to mind right away).




On Tue, Jul 10, 2018 at 3:21 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 10/07/2018 20:11, Kalle Sommer Nielsen wrote:
>
>> Den tir. 10. jul. 2018 kl. 21.08 skrev David Rodrigues <
>> david.proweb@gmail.com>:
>>
>>> I think that "or" could be removed if PHP could supports inline
>>> conditionals like:
>>>
>>> die() if !$connected;
>>> throw Exception() if fail();
>>> $x =3D $y if (z() && w());
>>>
>>> Or "when": die() when !$connected;
>>>
>>> It seems more clear than $connected or die().
>>>
>> I in fact find that more unreadable as you first got to dig through
>> the error handling before you actually get to the logic that triggered
>> it.
>>
>
>
> A more readable syntax, if we were designing from scratch, might be to
> look at SmallTalk, where ifTrue and ifFalse are methods on the boolean
> class, so can appear post-fix after any boolean, giving you something lik=
e:
>
> $connected ifFalse: die();
>

I hesitate to propose adding a new syntax to PHP, especially for something
so rarely used it makes me question if it's truly necessary.  If anything I
would think we should prefer a syntax that we can point to other languages
as examples (like the if/unless syntax from Ruby).  It feels odd to clean
up a rarely used operator by replacing it with fresh syntactical sugar.

On Tue, Jul 10, 2018 at 3:38 PM, Michael Morris <tendoaki@gmail.com> wrote:

> > 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.
>
>
>  True, but that's still a lot of code to break. A *lot* of code.  Far too
> much to consider changing this even at a major level I would think.
>
> PHP if anything, is too pragmatic a language for this change


I don't understand what you mean by a lot of code to break - this line
would be completely unaffected if the aliasing option was chosen.  By the
second line, I meant that PHP supports this behaviour in both the or and ||
operators.

--0000000000003289990570afe331--