Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102748
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAD2kNXBJSRTERURY5opb_r__KGWfmhXnfmb0HpaGfkA0_+bjZw@mail.gmail.com>
References: <CAD2kNXBHTo5pJv3sYfEZjgCE6t8Nshv8=VoAesb+eamDhUVRpQ@mail.gmail.com>
 <CAEUnE0eH2-Lkpnm9YyQERhGUVaEsBa-RDP8zuSkvNgL360Cr9g@mail.gmail.com> <CAD2kNXBJSRTERURY5opb_r__KGWfmhXnfmb0HpaGfkA0_+bjZw@mail.gmail.com>
Date: Wed, 11 Jul 2018 10:20:08 +0100
Message-ID: <CALKiJKqsQ7-UGM5WeY2xA5CTA_u_u8tzTWaT6-hfuwRex1w-fw@mail.gmail.com>
To: Ryan <iggyvolz@gmail.com>
Cc: Michael Morris <tendoaki@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cd65dc0570b5c06c"
Subject: Re: [PHP-DEV] Unifying logical operators
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000cd65dc0570b5c06c
Content-Type: text/plain; charset="UTF-8"

On 11 July 2018 at 03:20, Ryan <iggyvolz@gmail.com> wrote:

>
> 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.
>


There's a big difference between "not blindly updating" and "having to run
a static analysis tool and carefully read its results to stop your code
having a subtly different behaviour".

Introducing new errors is nearly always better than silently changing
behaviour (this is the entire principle of run-time type checks, after all).




> 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.
>


Right, which is why I said your *next* example, which did use assignment.
The point is that *reliably using the idiom* requires a specific
precedence, so that you don't have to carefully vet which other operators
are involved in the expression.




> > 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).
>

Perhaps I worded that badly. I was saying two things:

- The "do or die" idiom is extremely common in Perl. Just searching the
documentation should be enough to convince you of that:
https://duckduckgo.com/?q=site%3Aperldoc.perl.org+"or+die"
- Perl *also* has post-fix if and unless operators, which you had mentioned
in Ruby (Ruby inherited a lot from Perl). Clearly, people don't see these
as a better replacement for the use of "or".




> 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)
>


Just to reiterate, I strongly feel that aliasing is not an option. If the
aim is to reduce confusion, having the same code give different results in
different PHP versions is a massive own goal.




> 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.
>


Yes, hence "wanted to extend this syntax" - the suggestion is that this
would be a useful feature to add, not one that already exists.




> > 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.
>


I agree that adding new syntax is unnecessary for this, but since you keep
mentioning the postfix if/unless which Ruby inherited from Perl, I thought
I'd point to another language we could borrow syntax from, which is
actually closer to the current idiom ("condition keyword action", not
"action keyword condition").


Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000cd65dc0570b5c06c--