I was talking more about the inconsistency between return type void when it returns null. I'm asking whether this behavior has changed and functions without a return will now return void or ???. It's a pretty big inconsistency IMHO.
This is the same as other languages. In for example Java you have `public void method()`, and you then `return` which results in a `null`
Are you sure about that? I don't think you can use the results of void functions in Java as expressions.
Self-documenting code. I'm already using return types wherever I can, and it's nice to keep things consistent. Also, it helps prevent the abuse of interfaces. I can say "this method does not return values" and enforce it. That can be useful on a big project, with junior devs.
I was talking more about the inconsistency between return type void when it returns null. I'm asking whether this behavior has changed and functions without a return will now return void or ???. It's a pretty big inconsistency IMHO.
Functions with a `: void` return type will still give you a NULL if you use them in an expression. I didn't want to break the property of existing PHP functions that they can always be used as expressions. I reasoned that your IDE or whatever can always warn you if you mistakenly try to use the result of such a function.
PHP's built-in functions documented as "void" also return NULL, so I suppose there's an argument from consistency.
Self-documenting code. I'm already using return types wherever I can, and it's nice to keep things consistent. Also, it helps prevent the abuse of interfaces. I can say "this method does not return values" and enforce it. That can be useful on a big project, with junior devs.
I was talking more about the inconsistency between return type void when it returns null. I'm asking whether this behavior has changed and functions without a return will now return void or ???. It's a pretty big inconsistency IMHO.
Even if you have a point it wouldn't matter because making void functions return something else than null would be a big (useless) BC break.
There's a lot of code that uses "return;" to mean "return null;" and honestly I don't see it as a big problem.
... Note the syntax isn’t the usual double pipe || operator that we associate with or, rather a single pipe | character ... ... PHP 7.1 introduces visibility modifiers to constants ... ... With PHP 7.1 it is now possible to specify that a function has a void return type, i.e. it performs an action but does not return anything ... ... Example four contains numeric values, so everything else is stripped out, and the su…
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 f…
I didn't understand why the remark was there at all. Honestly | reminds me of sum types and it's the perfect choice here.
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…
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.
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.
"Fail Fast" is a pretty popular best-practice and failing immediately on a mismatched type hint is in line with that.
... Note the syntax isn’t the usual double pipe || operator that we associate with or, rather a single pipe | character ... ... PHP 7.1 introduces visibility modifiers to constants ... ... With PHP 7.1 it is now possible to specify that a function has a void return type, i.e. it performs an action but does not return anything ... ... Example four contains numeric values, so everything else is stripped out, and the su…
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 f…
> || 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: