On 11 July 2018 at 03:20, Ryan <iggyv...@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.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.
>
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 <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.
>
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]
