January 26, 2015 at 00:10PHP7 Revolution: Return Types and Artifact Removal
- Transfer
The planned release date of PHP7 is rapidly approaching, the internal group is working hard, trying to fix our favorite language, to make it as good as possible, artifacts of previous versions will be deleted and several features so desired will be added. There are many RFCs that can be explored and discussed, but in this post I would like to focus on the three most important.
As I said in a previous letter , 5.7 was rejected in favor of switching directly to PHP7. This means that there will be no new version between 5.6 and 7 - even if it would appear, it would simply serve as a signal to those who are still mired in outdated code. Initially, 5.7 was not supposed to have new features, but it was supposed to throw out notifications and warnings about code obsolescence, which will soon change in v7.
It is also necessary to warn about some keywords that will be reserved in PHP7 so that people can quickly bring their code into compliance using some kind of “automatic” check of compatibility of PHP versions. However, as I wrote on the newsletter, most people who are competent enough to maintain compatibility of their code with the latest version of PHP do not actually use constructs that PHP7 can break.
Please note that while the vote is mixed, this suggests that the idea is not finally buried. Participants speak out against 5.7 due to the lack of significant changes, but given the new votes on other RFCs, they may well change their mind. Let's see what happens.
With the overwhelming majority of the votes cast, PHP finally got return types. The voting results are still fresh, but definite. Starting with PHP7, we can finally specify the correct return type for the function:
Improvement? Definitely !!! But is it perfect? Unfortunately not:
Some people also complained about type declarations after the closing bracket of the argument list, and not before the function name, but for me it's nitpicking. Popular languages, such as modern C ++, use a “post” syntax, while retaining the ability to search for “function foo” without having to resort to regex modifications. Moreover, this is consistent with the use of HHVM, thus resulting in an unexpected compatibility bonus.
Others complained about the "rigor" of PHP, but, as one of the commentators stated, you really should know what you want to get before you start coding, through interfaces and inheriting someone else's code. In addition, while specifying return types is optional, and its presence does not affect the overall performance or stability of PHP, you do not need to inflate the problem out of this. Complaining about such a feature is like complaining about OOP in PHP at a time when procedural spaghetti was a good way to solve the problem. Languages evolve, and this is one of the steps in the right direction.
What do you think?
The upcoming version offers to remove the stylistic constructs of PHP4 (not yet voted). You can read and understand this RFC, it's simple, and it would be useless to repeat again - the language goes forward. I don’t understand why such a step causes MUCH mental anguish in some people. For example, here : “Please do not destroy our language,” asks Tony, who seems to use deleted functionality with some intent.
The post is very well written and, despite the obvious anger, it makes me wonder if you have such a codebase for so long, is it worth it to upgrade to PHP7? And if you really want so much, is it worth it to drag all this with you, isn't it easier to identify broken classes and fix their constructors? You can even delegate this task to juniors, provided that the code is sufficiently covered by tests, you can always make sure that nothing is broken. And even if there are no tests, if your application is a piece of code of incomprehensible quality, are you really hoping to get the benefit of moving to PHP7? Isn't it better to update your application first?
Sentence“The code that I wrote 10 years ago should still be launched today and should be able to execute it in 10 years” - for me it’s crazy - you certainly should not expect this from any popular language as part of the transition from one main its version to another. Draw a parallel with the real world, you should not expect permission to have slaves today, just because once upon a time the law allowed it. Yes, there was a bloody transition, but when most of the supporters of slavery either repented or died, peace came.
It is worth paying tribute to Tony, he is right in defending his opinion and making a large amount of effort so that his firm "no" is heard. But in the long run, it will take more collective effort to troubleshoot issues with designers than if you just get rid of the problem right now.
It is clear that broken compatibility will always upset some people, even if everything remains normal in the main versions, breaking compatibility is necessary for the purpose of progress. Imagine a howl that rises when such people learn about it . Damn, if last year had not been updated
My advice to those who fear PHP7 is stop. If you do not want to be updated, then do not do this. If you have been sitting on 5.3 or 5.2 for so long (hello, CodeIgniter lovers), then sit on 5.6 for another ten years, do not bother PHP to be modern. Leave the progress to those who are ready to accept it.
What do you think about this? Is this all delirious artifact removal or a really necessary step?
As an interesting marginal note, there are some changes in PHP7 that may cause a slight delay in porting extensions to version 7. The API for creating extensions fell under refactoring (cleaning) and everything can change, however, this provocative tweet from Sara Golemon gathered a little attention.
She basically says that the changes in creating extensions when switching from 5.6 to 7 will be so big that it’s easier to learn how to do extensions under HHVM. And then she continues to develop the topic with a series of articles on how to create an HHVM extension .
Are you developing extensions? Have you studied the changes and how do you feel about all this, is it too early to talk about the future effect now?
Edit : My attention was drawn to the fact that after all this, Sarah began to document a new extension API compatible with both HHVM and PHP7. It looks like you can make extensions compatible with both runtimes!
As usual, the PHP world does not lack drama. As with all major revolutions, throughout the history of PHP7, blood will also be shed before something amazing happens. PHP7 is still far away, so even if you are caught in the crossfire of musket shots, there is enough time to get to the exit. If you sleep under the caterpillar of the tank , then both sides can do little to help you.
What do you think of these RFCs? How do you feel about PHP7 in general? Is he moving in the right direction? Let us know - we want to hear your thoughts!
PHP 5.7 vs. PHP7
As I said in a previous letter , 5.7 was rejected in favor of switching directly to PHP7. This means that there will be no new version between 5.6 and 7 - even if it would appear, it would simply serve as a signal to those who are still mired in outdated code. Initially, 5.7 was not supposed to have new features, but it was supposed to throw out notifications and warnings about code obsolescence, which will soon change in v7.
It is also necessary to warn about some keywords that will be reserved in PHP7 so that people can quickly bring their code into compliance using some kind of “automatic” check of compatibility of PHP versions. However, as I wrote on the newsletter, most people who are competent enough to maintain compatibility of their code with the latest version of PHP do not actually use constructs that PHP7 can break.
Please note that while the vote is mixed, this suggests that the idea is not finally buried. Participants speak out against 5.7 due to the lack of significant changes, but given the new votes on other RFCs, they may well change their mind. Let's see what happens.
Return types (Return Types)
With the overwhelming majority of the votes cast, PHP finally got return types. The voting results are still fresh, but definite. Starting with PHP7, we can finally specify the correct return type for the function:
function foo(): array {
return [];
}
Improvement? Definitely !!! But is it perfect? Unfortunately not:
- can be returned only those types that have at the moment ...
will not be able to return scalar values, such asstring,int,bool, and others. This means that your methods and functions that return similar values still remain in their original state.
You can fix this by returning wrapper instances for similar values, but this will be an unnecessary perversion in most cases. (approx. lane - it's time to pay attention to one of the previous endeavors - the transformation of primitives into normal objects ) - it will not be possible to determine the return of several types. If your function returns either an array or an object
Iterator, then there is no way to specify this, for example,array|Iteratoras we do in doc blocks.
Some people also complained about type declarations after the closing bracket of the argument list, and not before the function name, but for me it's nitpicking. Popular languages, such as modern C ++, use a “post” syntax, while retaining the ability to search for “function foo” without having to resort to regex modifications. Moreover, this is consistent with the use of HHVM, thus resulting in an unexpected compatibility bonus.
Others complained about the "rigor" of PHP, but, as one of the commentators stated, you really should know what you want to get before you start coding, through interfaces and inheriting someone else's code. In addition, while specifying return types is optional, and its presence does not affect the overall performance or stability of PHP, you do not need to inflate the problem out of this. Complaining about such a feature is like complaining about OOP in PHP at a time when procedural spaghetti was a good way to solve the problem. Languages evolve, and this is one of the steps in the right direction.
What do you think?
Artifact Removal
The upcoming version offers to remove the stylistic constructs of PHP4 (not yet voted). You can read and understand this RFC, it's simple, and it would be useless to repeat again - the language goes forward. I don’t understand why such a step causes MUCH mental anguish in some people. For example, here : “Please do not destroy our language,” asks Tony, who seems to use deleted functionality with some intent.
The post is very well written and, despite the obvious anger, it makes me wonder if you have such a codebase for so long, is it worth it to upgrade to PHP7? And if you really want so much, is it worth it to drag all this with you, isn't it easier to identify broken classes and fix their constructors? You can even delegate this task to juniors, provided that the code is sufficiently covered by tests, you can always make sure that nothing is broken. And even if there are no tests, if your application is a piece of code of incomprehensible quality, are you really hoping to get the benefit of moving to PHP7? Isn't it better to update your application first?
Sentence“The code that I wrote 10 years ago should still be launched today and should be able to execute it in 10 years” - for me it’s crazy - you certainly should not expect this from any popular language as part of the transition from one main its version to another. Draw a parallel with the real world, you should not expect permission to have slaves today, just because once upon a time the law allowed it. Yes, there was a bloody transition, but when most of the supporters of slavery either repented or died, peace came.
It is worth paying tribute to Tony, he is right in defending his opinion and making a large amount of effort so that his firm "no" is heard. But in the long run, it will take more collective effort to troubleshoot issues with designers than if you just get rid of the problem right now.
It is clear that broken compatibility will always upset some people, even if everything remains normal in the main versions, breaking compatibility is necessary for the purpose of progress. Imagine a howl that rises when such people learn about it . Damn, if last year had not been updated
mysqliinsteadmysql, either WordPress could not work correctly on PHP7, or PHP7 would be full of holes and hopelessly outdated for the sole reason that core developers took pity on WP users and decided to leave them happy. My advice to those who fear PHP7 is stop. If you do not want to be updated, then do not do this. If you have been sitting on 5.3 or 5.2 for so long (hello, CodeIgniter lovers), then sit on 5.6 for another ten years, do not bother PHP to be modern. Leave the progress to those who are ready to accept it.
What do you think about this? Is this all delirious artifact removal or a really necessary step?
Aside: Extension API changes
As an interesting marginal note, there are some changes in PHP7 that may cause a slight delay in porting extensions to version 7. The API for creating extensions fell under refactoring (cleaning) and everything can change, however, this provocative tweet from Sara Golemon gathered a little attention.
Damn. There are some serious surprises in the PHP7 Extension API changes. Not for nothin ', but it's a good time to switch to HHVM.
- SaraMG (@SaraMG) January 3, 2015
She basically says that the changes in creating extensions when switching from 5.6 to 7 will be so big that it’s easier to learn how to do extensions under HHVM. And then she continues to develop the topic with a series of articles on how to create an HHVM extension .
Are you developing extensions? Have you studied the changes and how do you feel about all this, is it too early to talk about the future effect now?
Edit : My attention was drawn to the fact that after all this, Sarah began to document a new extension API compatible with both HHVM and PHP7. It looks like you can make extensions compatible with both runtimes!
Conclusion
As usual, the PHP world does not lack drama. As with all major revolutions, throughout the history of PHP7, blood will also be shed before something amazing happens. PHP7 is still far away, so even if you are caught in the crossfire of musket shots, there is enough time to get to the exit. If you sleep under the caterpillar of the tank , then both sides can do little to help you.
What do you think of these RFCs? How do you feel about PHP7 in general? Is he moving in the right direction? Let us know - we want to hear your thoughts!