PHP looks more and more like Java.
Or Typescript...but that makes me happy. IDE help and type checking that code you haven't touched in months is so worth it
Upcoming changes in PHP 7.1
41–50 of 137 posts
Re: Upcoming changes in PHP 7.1
#42Not mentioned in the article: Several RFCs being voted on or discussed right now.
Re: Upcoming changes in PHP 7.1
#43I'm more excited by some features not detailed in the article. Return type declarations, which were introduced in PHP 7.0, are being enhanced somewhat. First, it's now possible to declare nullable return types (previously all return types did not permit null): public function getFoo(): ?int; (You can also use ? on parameter and property types.) Second, we now have a void return type for functions where there is no us…
What is the reasoning for type hinting void when the PHP manual specifies that a NULL value is returned if the return is omitted? http://php.net/manual/en/functions.returning-values.php
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.
Re: Upcoming changes in PHP 7.1
#44I'm more excited by some features not detailed in the article. Return type declarations, which were introduced in PHP 7.0, are being enhanced somewhat. First, it's now possible to declare nullable return types (previously all return types did not permit null): public function getFoo(): ?int; (You can also use ? on parameter and property types.) Second, we now have a void return type for functions where there is no us…
> Disclaimer: I wrote the void return type RFC and implementation, so I'm biased here.
I'll take this opportunity to say thank you, for this, and all the other hard work you put into PHP internals.
Re: Upcoming changes in PHP 7.1
#45> Catching multiple exception types > Support class constant visibility Reminds me of what Rob Pike once said, "[Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more] are converging into a single huge language".
As someone who works predominantly with PHP and JavaScript, but has spent some time with Java, Ruby and Python - I actually agree with you!
Bob says "I wish PHP had this thing from Java" and Alice says "I wish Java had this thing from PHP". I don't think it's necessarily a bad thing.
Re: Upcoming changes in PHP 7.1
#46Earlier quoted context omitted.
What is the reasoning for type hinting void when the PHP manual specifies that a NULL value is returned if the return is omitted? http://php.net/manual/en/functions.returning-values.php
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.
Re: Upcoming changes in PHP 7.1
#47Earlier quoted context omitted.
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 the…
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.
Re: Upcoming changes in PHP 7.1
#48Earlier quoted context omitted.
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.
It's a good point, and one which I personally hadn't thought about. The RFC specifically mentions it, so it's obviously a concern:
> Choosing one over the other suggests intent. If you specify a value, it suggests the value is significant. In a void function, the return value is insignificant: it's always the same and has no actual usefulness. https://wiki.php.net/rfc/void_return_type#why_isn_t_return_n...
I guess this 'pragmatism over consistency' fits in with the general ethos of PHP. I guess it's why so many people hate it, but I can't imagine a situation in which this will actually cause a problem.
Re: Upcoming changes in PHP 7.1
#49Earlier quoted context omitted.
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.
[deleted]
Re: Upcoming changes in PHP 7.1
#50Earlier quoted context omitted.
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.
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`