PHP7 revolution: return types and artifact removal
The planned release date of PHP7 is rapidly approaching, the internal team is working hard, trying to fix our favorite language, to make it as good as possible, to remove the artifacts of previous versions and to add a few so desired features. There are many RFCs that can be studied and discussed, but in this post I would like to focus on the three most important ones.
As I said in the last letter , 5.7 was rejected in favor of going directly to PHP7. This means that there will not be a new version between 5.6 and 7 - even if it appeared, it would simply serve as a signal to those who are still bogged down with obsolete code. Initially, 5.7 should not have had new functions, but should have thrown out notifications and warnings about the obsolescence of the code, which will soon change in v7.
You also need to be warned about some keywords that will be reserved in PHP7 so that people can quickly align their code with some kind of “automatic” PHP version compatibility check. However, as I wrote in the ezine, most people who are competent enough to keep their code compatible with the latest version of PHP do not actually use constructs that can break PHP7.
Please note that while the vote is ambiguous, this suggests that the idea is not completely buried. Participants oppose 5.7 due to the lack of significant changes, but given the new votes at other RFCs, they may well change their mind. Let's see what happens.
With the overwhelming majority of votes in favor, PHP finally got the return types. The voting results are still fresh, but certain. Beginning with PHP7, we can finally specify the correct type of return value 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 this is a nagging one. Popular languages ​​such as modern C ++ use the “post” syntax, while retaining the ability to search for “function foo” without any need to resort to regex modifications. Moreover, it is consistent with the fact that it uses HHVM, thus an unexpected bonus in compatibility is obtained.
Others complained about the “rigor” of PHP, but, as one of the commentators said, you really should know what you want to get even before the coding begins, through the interfaces and the inheritance of someone else's code. In addition, as long as the indication of returned types is optional, and its presence does not affect the overall performance or stability of PHP, there is no need to inflate the problem. Complaining about this feature is like complaining about the presence of OOP in PHP at a time when procedural spaghetti was a good way to solve the problem. Languages ​​evolve, and this is one step 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 it again - the language goes forward. I don’t understand why such a move causes SO MUCH mental anguish in some people. For example, here : “Please do not destroy our language,” asks Tony, who seems to use the removed functionality with a certain intent.
The post is very well written and, despite the obvious anger, makes me wonder - if you have such a code base lives for so long, is it worth it to upgrade to PHP7? And if you really want to, then is it worth dragging all this with you, isn't it easier to identify broken classes and fix their designers? You can even delegate this task to the juniors, provided that the code is sufficiently covered with 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, do you really hope to get the benefit of moving to PHP7? Wouldn't it be better to upgrade your app first?
The sentence "the code I wrote 10 years ago still has to be launched today and it should be possible to execute it in 10 years" - for me, madness - you certainly should not expect this from any popular language as part of the transition from one its main version to another. Draw a parallel with the real world, you should not expect permission to have slaves today, just because the law allowed it long ago. Yes, there was a bloody transition, but when most supporters of slavery either repented or died, peace came.
It is necessary to pay tribute to Tony, he is right in that he defends his opinion and makes a lot of effort so that his firm “no” is heard. But in the long run, it will take more collective efforts to eliminate problems with the designers, than if you just get rid of the problem right now.
Clearly, broken compatibility will always upset some people, even if everything remains normal within the basic versions, breaking compatibility is necessary for the purposes of progress. Imagine the howl that will rise when such people find out about it . Damn, if last year
My advice to those who fear PHP7 - stop. If you do not want to be updated, then do not do it. 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 stop PHP from being up-to-date. Leave progress for those who are willing to accept it.
What do you think about this? This whole idea with the removal of artifacts is nonsense or is it really a necessary step?
As an interesting note on the margins, there are some changes in PHP7 that can cause a slight delay in porting extensions to version 7. The API for creating extensions has been refactored (purged) and things can change, however this provocative tweet from Sara Golemon gathered some attention.
It basically says that the changes in creating extensions when moving from 5.6 to 7 will be so large that it is easier to learn how to make extensions under HHVM. And then she continues to develop the theme with a series of articles on how to create the 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?
Edit : My attention was drawn to the fact that Sarah, after all this, began to document the new extension API, compatible with both HHVM and PHP7. It seems that you can make extensions compatible with both runtimes!
As usual, the PHP world does not experience a lack of 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 plenty of time to get to the exit. If you sleep under a tank caterpillar , 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 the last letter , 5.7 was rejected in favor of going directly to PHP7. This means that there will not be a new version between 5.6 and 7 - even if it appeared, it would simply serve as a signal to those who are still bogged down with obsolete code. Initially, 5.7 should not have had new functions, but should have thrown out notifications and warnings about the obsolescence of the code, which will soon change in v7.
You also need to be warned about some keywords that will be reserved in PHP7 so that people can quickly align their code with some kind of “automatic” PHP version compatibility check. However, as I wrote in the ezine, most people who are competent enough to keep their code compatible with the latest version of PHP do not actually use constructs that can break PHP7.
Please note that while the vote is ambiguous, this suggests that the idea is not completely buried. Participants oppose 5.7 due to the lack of significant changes, but given the new votes at other RFCs, they may well change their mind. Let's see what happens.
Return Types
With the overwhelming majority of votes in favor, PHP finally got the return types. The voting results are still fresh, but certain. Beginning with PHP7, we can finally specify the correct type of return value for the function:
')
function foo(): array { return []; } Improvement? Definitely !!! But is it perfect? Unfortunately not:
- only the types that are currently available can be returned ...
It will not be possible to return scalar values ​​such asstring,int,bool, etc. This means that your methods and functions that return such values ​​will 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 undertakings - 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
Iteratorobject, 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 this is a nagging one. Popular languages ​​such as modern C ++ use the “post” syntax, while retaining the ability to search for “function foo” without any need to resort to regex modifications. Moreover, it is consistent with the fact that it uses HHVM, thus an unexpected bonus in compatibility is obtained.
Others complained about the “rigor” of PHP, but, as one of the commentators said, you really should know what you want to get even before the coding begins, through the interfaces and the inheritance of someone else's code. In addition, as long as the indication of returned types is optional, and its presence does not affect the overall performance or stability of PHP, there is no need to inflate the problem. Complaining about this feature is like complaining about the presence of OOP in PHP at a time when procedural spaghetti was a good way to solve the problem. Languages ​​evolve, and this is one step in the right direction.
What do you think?
Removing artifacts
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 it again - the language goes forward. I don’t understand why such a move causes SO MUCH mental anguish in some people. For example, here : “Please do not destroy our language,” asks Tony, who seems to use the removed functionality with a certain intent.
The post is very well written and, despite the obvious anger, makes me wonder - if you have such a code base lives for so long, is it worth it to upgrade to PHP7? And if you really want to, then is it worth dragging all this with you, isn't it easier to identify broken classes and fix their designers? You can even delegate this task to the juniors, provided that the code is sufficiently covered with 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, do you really hope to get the benefit of moving to PHP7? Wouldn't it be better to upgrade your app first?
The sentence "the code I wrote 10 years ago still has to be launched today and it should be possible to execute it in 10 years" - for me, madness - you certainly should not expect this from any popular language as part of the transition from one its main version to another. Draw a parallel with the real world, you should not expect permission to have slaves today, just because the law allowed it long ago. Yes, there was a bloody transition, but when most supporters of slavery either repented or died, peace came.
It is necessary to pay tribute to Tony, he is right in that he defends his opinion and makes a lot of effort so that his firm “no” is heard. But in the long run, it will take more collective efforts to eliminate problems with the designers, than if you just get rid of the problem right now.
Clearly, broken compatibility will always upset some people, even if everything remains normal within the basic versions, breaking compatibility is necessary for the purposes of progress. Imagine the howl that will rise when such people find out about it . Damn, if last year
mysqli was not updated instead of mysql , then 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 regretted WP users and decided to leave them happyMy advice to those who fear PHP7 - stop. If you do not want to be updated, then do not do it. 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 stop PHP from being up-to-date. Leave progress for those who are willing to accept it.
What do you think about this? This whole idea with the removal of artifacts is nonsense or is it really a necessary step?
Towards: Extension API changes
As an interesting note on the margins, there are some changes in PHP7 that can cause a slight delay in porting extensions to version 7. The API for creating extensions has been refactored (purged) and things can change, however this provocative tweet from Sara Golemon gathered some attention.
Damn. There are some serious surprises in the PHP7 Extension API changes. Not for nothin ', but for a switch to HHVM.
- SaraMG (@SaraMG) January 3, 2015
It basically says that the changes in creating extensions when moving from 5.6 to 7 will be so large that it is easier to learn how to make extensions under HHVM. And then she continues to develop the theme with a series of articles on how to create the 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?
Edit : My attention was drawn to the fact that Sarah, after all this, began to document the new extension API, compatible with both HHVM and PHP7. It seems that you can make extensions compatible with both runtimes!
Conclusion
As usual, the PHP world does not experience a lack of 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 plenty of time to get to the exit. If you sleep under a tank caterpillar , 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!
Source: https://habr.com/ru/post/248721/
All Articles