I don't like PHP either, but that doesn't mean kneejerk reactions are excusable, and at the least on the first point you are wrong. Using | instead of || is not an inconsistency, but actually quite consistent.

|| is a short-cutting or comparison operator which returns the first true thing it encounters.

| is a bitwise or combinator, which takes two sets of flags, and combines them into one set of flags that has all flags activated which were also active in the input sets.

Semantically, | is absolutely the correct choice here.

A better question would be why there's a $2 there, though i hope that's just a typo and means $e.

> || is a short-cutting or comparison operator which returns the first true thing it encounters.

I wish. The fact that it actually doesn't is one of the things that really bugs me about PHP:

    <?php
    var_dump(0 || 42);

The above example will output:

    bool(true)

PHP does have the shorthand ternary operator `?:`, though, which does what you want here:

  $ php -r 'var_dump(0 || 42);'
  bool(true)
  $ php -r 'var_dump(0 ?: 42);'
  int(42)

Wow. OK, I am a big user of the ternary operator, but I hadn't come across omission of the middle part until now. To be honest, it's not the most accessible syntax (especially if you're coming from another language), but at least I have the option now - thanks!

edit: Just to clarify for anyone else unfamiliar with it:

    $ php -r 'var_dump(42 ?: 0);'
    int(42)

Depending on how far back you have to support (e.g., WordPress is still supporting 5.2), omission of the middle part wasn't supported until PHP 5.3.

5.3 came out seven years ago and isn't even officially supported by the PHP project now, let alone 5.2.

I know all too well, and you'd never catch me running that on any of my own systems. With a large enough install base, it's not uncommon to have a decent number of people on those older versions though.

Actually || is short circuiting and behaves exactly as he described, it returns the first true thing it encounters.

  $ php -a
  Interactive shell
  
  php > echo 1 || die('die');
  1

This echo's 1, it doesn't die.

... ok, i gotta admit i had my Perl hat on for that reply.

You were actually correct -- see my above reply.

This is correct. PHP makes extensive use of bitwise operators for function options. For examples, see json_encode, htmlentities, filter_input, etc.

I didn't understand why the remark was there at all. Honestly | reminds me of sum types and it's the perfect choice here.

The reason I added this was because most developers are used to using a double pipe when writing code that has 'or' conditions.

I understand the use of pipes for bitwise, but in this case if you read the code in the example, we're basically saying "if the exception is of type A or of type B", personally I'd be inclined to use || if I didn't already know the syntax.

Indeed it was a typo, i've now fixed that in the article. Thanks.

Better yet, don't reinvent the world and just use commas?

Commas are used in PHP as a sequence of things, not multiple options. This single-pipe notation is already established as the further-up comments states.

> Commas are used in PHP as a sequence of things

Choosing a pipe because it's easier for an obscure language feature, is not least astonishment. Commas are used for lists. The pipe is a bad choice among a nice feature.

Commas would require changing the syntax and implementation of catch. This way exception names just become first class subjects that can be combined with an overloaded operator.

This hot take is both pretty uncharitable and largely incorrect.

... "catch (FooException | BarException" is new syntax that would be a include-time fatal in existing code

... "public const FOO" is new syntax that would be a include-time fatal in existing code; public is the default modifier in the language when no visibility modifier is present, so existing code functions exactly the same as before

... ": void" return type only conflicts with existing code if a class is named Void, which becomes an error for the file declaring the class ... this is vanishingly unlikely [0] and an easy grep to fix; if you're looking at some code "$var = i_return_void();", the annotation is a clear sign that the "$var =" part is obviously confused.

... " 5 + 'a string' " is nonsense code which codebases that care about warnings currently want to be aware of.

[0] even the few hits for https://github.com/search?utf8=%E2%9C%93&q=%22class+Void+%22... are mostly false positives.

Which inconsistencies are those? Functions that return; or don't return at all already return null in PHP.

I suppose its not an inconsistency as such, but I included it because I thought it was funny.

I wonder why PHP includes more and more type checks and visibility features, when all those checks are performed at runtime. What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification. I mean, I get that type checks are useful for IDEs, but enforcing these rules at runtime using fatal errors just does not make any sense to me.

If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code. And as the maker of the sibling comment notes, runtime type checks still catch errors earlier than no type checks.

Moreover, having these declarations actually be part of the language, even if the interpreter itself cannot enforce them ahead-of-time, means tooling can be built around it, and we can use them for optimisations in the VM (which PHP 7.1 does: we elide type checks on certain arithmetic operations for operands of known types).

If you want to ensure type safety before the program actually runs, you can of course let your IDE or static analyser check that for you.

> If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code.

I think types specifications in interpreted (not compiled) languages should be only hints (for IDEs, code analyzers and JIT compilation etc.). This type checking for every method probably also adds some overhead does it not?

EDIT: correction

Yes, it adds overhead. But it means the type declaration can actually be relied upon: the code inside the function always gets the type it wants, the optimiser can elide type checks safely, and humans and computers reading the code don't have to worry about the type declaration being a lie.

Unenforced type hints don't give these guarantees. They have no requirement to be accurate because the runtime won't enforce them, so they're essentially documentation, not code. They can't be safely relied upon by the optimiser because they're unenforced. The code inside the function body can break at runtime if given the wrong type, so if having a specific type is particularly important, you have to add manual type checks or coercions yourself.

But these checks could also be performed by a code analyzer/compiler, removing this burden from the runtime. (Performing the checks at runtime, means the code is only checked when it is executed, which could be at any random time.)

Ahead-of-time type checking can only really work if the entire program has type declarations everywhere, and if you know what constitutes the entire program. This isn't the case for the vast majority of existing PHP code. Furthermore, PHP's dynamic features mean that there are cases where ahead-of-time checks will always be impossible. So you have to have at least some runtime checks, at the boundaries between typed and untyped code.

Furthermore, doing ahead-of-time checking would require infrastructure we don't currently have for providing information to the PHP interpreter about whether or not PHP files have passed type checks. But again, most code is not fully typed, and so this doesn't provide all that many guarantees to the interpreter.

I've seen quite a few JavaScript bugs and potential bugs exposed after adding incomplete type annotations in TypeScript, so I really don't think it's all or nothing, at least not as a general rule. I've been away from PHP too long to speculate how much it would help here.

Sure, it's not all-or-nothing, type checks that aren't enforced at runtime have some benefits, I just disagree that they can provide all of them.

If you're using type signatures, the alternative is probably going to be that your program crashes at a later time. "Foo is not a Bar" is a better error message than "$foo->xyz() isn't a function", and this happens much closer to the point where you've messed up.

I disagree. I think that this type of "late type binding" is actually an advantage of dynamically typed languages. That way it does not matter if you pass a map/array/dictionary or an instance of a class as long as the properties are the same.

I think one problem is when your object quacks like a duck, but the quack doesn't mean what you think it means.

Having methods that just have the right names is a pretty weak assurance, isn't it?

"Fail Fast" is a pretty popular best-practice and failing immediately on a mismatched type hint is in line with that.

The type hinting is optional, so if you want "late type binding" you can just omit the type hints.

Then... don't specify that you want a specific type?

PHPDoc is supported by most IDE's. Using this you can specify parameter types without using the actual type system.

Visibility and typing features are good. Visibility helps to design and write better code. The typing features are also welcomed in my view. I would rather a request completely fails because a variable is the wrong type rather than PHP's type coercion leading to an unexpected result with no errors or warnings.

That said, I use PHP for my day job. I see no reason to start new projects in it. I never use it in my side projects. Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion.

7.1 does more work to improve consistency and error handling which is definitely welcomed. The problem is there is much legacy crap in PHP. It only exists for web applications and there are a growing number of languages which do this better.

> Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion.

I kind of understand it since it's not a traditional OR operation and intends to keep and associate the matching values, but maybe something like

catch (Exception $e in (Exceptions...))

would make it clearer. Either way, it's so close to feeling like an OR operation that I feel like it will be a lot of debugging when you forget this.

> What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification.

The good it does is it stops your application from possibly continuing on with buggy code.

This is especially important in something like billing code. Imagine if your code was expecting an integer (bill amount) but got a string instead that via the types system evaluated to 0 or 1 instead of the real integer... In that case you might charge customers less or more than you should have and its a big deal trying to get all that fixed.

Better to just throw an error which you can see in an exception handling system like Sentry and take care of the problem.

>I wonder why PHP includes more and more type checks and visibility features

Because they are easy to implement (function type hints, typed properties) and the php community have a collective, insatiable, perpetual hardon for features that are supposed to enhance correctness..

So the core devs are eager to propose these kinds of features. And the community is eager to accepts them without much thought..

To see how child like this mentality towards these type of features, see this comment, where a Php expert makes a big deal regarding when a user omitted mentioning the type of a value....

https://www.reddit.com/r/PHP/comments/4k2htl/ive_just_given_...