Unifying logical operators View as Markdown

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, so
those are a different feature again).

It seems to me the “do this or die” idiom at least has been very common
in PHP. There may still be some occurences in the manual proper, and
definitely there are occurences in user contributed notes.

Finally, a note on the "xor" operator - your draft says that this is
equivalent to "!=", but that is not the case, because both can operate on
non-boolean values. Consider "1 != 2" (true) vs "1 xor 2" (false). I don'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.

“xor” is equivalent to ^ (sans the precedence).

--
Christoph M. Becker

While having these behave they do is unfortunate, it is hardly the only one
of PHP's quirks. Ever looked at the ramifications of loose typing with
comparison?http://phpsadness.com/sad/52

Eugh, I hate that site, and I hate that it's so widely linked as though
it's some kind of well-researched resource rather than the ramblings of
one rather opinionated developer.

That's one of the more reasonable pages, but it's still an awful lot of
words and spurious diagrams to say "coercing values means comparisons
are intransitive in certain situations (most of which you'd never notice
in every day use)".

Regards,

--
Rowan Collins
[IMSoP]

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

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=defined("X") or die() - however that would be pointless as
$isDefined would always be true.

($gdImage = @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, so
those are a different feature again).

Forgive my lack of knowledge with perl, but it looks1 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 => y if x, x or y => 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 would
just lead to even more confusion when they don't work the same way as in
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
!= as I thought)

Finally, a note on the "xor" operator - your draft says that this is
equivalent to "!=", but that is not the case, because both can operate on
non-boolean values. Consider "1 != 2" (true) vs "1 xor 2" (false). I don'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.

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=self::findFile("subdirectory") and return $file;
(continuing the loop if it didn't return). However, this isn't possible
since return is a language construct.

isset($foo) OR $foo = '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=$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:

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 = $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 like:

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

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.