On Tue, Jul 10, 2018 at 2:26 AM, Walter Parker <walt...@gmail.com> wrote:
>
> 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.coll...@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 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 => 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.
On Tue, Jul 10, 2018 at 2:37 PM, Kalle Sommer Nielsen <ka...@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=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.
[1]: http://perl101.org/flow-control.html
On Tue, Jul 10, 2018 at 2:58 PM, Andrey Andreev <n...@devilix.net> wrote:
> 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.coll...@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.pro...@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.
On Tue, Jul 10, 2018 at 3:38 PM, Michael Morris <tendo...@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.
