With the planned date for PHP 7’s release rapidly approaching, the internals group is hard at work trying to fix our beloved language as much as possible by both removing artifacts and adding some long desired features. There are many RFCs we could study and discuss, but in this post, I’d like to focus on three that grabbed my attention.
随着PHP 7发布计划日期的临近，内部人员小组正努力通过消除工件和添加一些长期期望的功能来尽可能地修复我们心爱的语言。 我们可以研究和讨论许多RFC，但是在这篇文章中，我想重点介绍三个引起我注意的RFC。
As I mentioned in the last newsletter, 5.7 has been downvoted in favor of moving directly to PHP 7. This means there will be no new version between 5.6 and 7 – even if the new version was only to serve as a warning light to those still stuck on outdated code. Originally, 5.7 was not supposed to have new features, but was supposed to throw out notices and warnings of deprecation about code that’s about to change in v7.
正如我在上一期新闻中提到的那样，5.7已被否决以支持直接迁移到PHP7。这意味着在5.6和7之间不会有新版本-即使新版本只是对那些仍在使用中的人提供警告。卡在过时的代码上。 最初，5.7不应该具有新功能，但是应该丢弃有关v7中将要更改的代码的过时通知和警告。
It would also warn about some keywords that are to be reserved in PHP 7, so that people can bring their code up to speed with a sort of “automatic” compatibility checker in the form of an entire PHP version. The thing is, however, as I argue in the newsletter, that most people technologically competent enough to follow PHP in its upgrade path by keeping up with the most recent version aren’t generally the type of people to actually be using code that might break in PHP 7.
它还会警告某些在PHP 7中保留的关键字，以便人们可以使用整个PHP版本形式的“自动”兼容性检查器来加快其代码的运行速度。 但是，正如我在时事通讯中指出的那样，大多数人在技术上足够胜任，可以通过与最新版本保持一致来遵循PHP的升级路径，实际上并不是那种真正会使用可能破坏代码的人。在PHP 7中。
Note that while the voting is over, that doesn’t prevent it from being resurrected at a later point in time. The “nay” voters in the first round seem to have argued against 5.7 due to the lack of significant changes, but with recent changes and new votes on other RFCs, that may well be reconsidered. Let’s see what happens.
请注意，虽然投票结束了 ，但这并不能阻止它在以后的某个时间复活。 由于缺乏重大变化，第一轮的“反对”选民似乎反对5.7，但是随着最近的变化以及对其他RFC的新投票，很可能会重新考虑。 让我们看看发生了什么。
With a vast majority voting “yes”, PHP is finally getting return types. The results of the vote are still fresh, but definite. Starting with PHP 7, we’ll finally be able to indicate proper return types on functions in the form of:
在绝大多数人赞成的情况下，PHP终于获得了回报类型。 投票结果仍然是新鲜的，但是肯定的。 从PHP 7开始，我们最终将能够以下列形式指示函数的正确返回类型：
function foo(): array { return []; }An improvement? Definitely! But perfect? Unfortunately, no:
一种提升？ 绝对！ 但是完美吗？ 抱歉不行：
the return types can only be what we have for types right now, meaning no scalar values, no return types like string, int, bool, etc. This means that your methods and functions that return such values will still be unsigned. You can remedy this by returning instances of wrappers for such values, but that’s overkill in the vast majority of cases.
返回类型只能是我们现在具有的类型，这意味着没有标量值，没有字符串 ， int ， bool等返回类型。这意味着返回此类值的方法和函数仍将是无符号的。 您可以通过返回此类值的包装实例来解决此问题，但这在绝大多数情况下是过大的。
no multiple return types. If your function returns either an array, or an Iterator object, there’s no way to indicate that via, for example, array|Iterator as we do in docblocks.
没有多个返回类型。 如果您的函数返回数组或Iterator对象，则无法像在文档块中那样通过array|Iterator进行指示。
Some people also complained about the type declaration being after the closing parenthesis of the argument list, rather than before the function name, but to me, this is nitpicking. Popular languages such as modern C++ use the “after” syntax, and like the RFC states, this preserves the possibility of searching for “function foo” without any necessary regex modifications. What’s more, this is in line with what HHVM uses, so it’s an added unintended compatibility bonus.
有些人还抱怨类型声明是在参数列表的右括号后面，而不是在函数名称之前，但是对我来说，这很挑剔。 诸如现代C ++之类的流行语言都使用“ after”语法，并且像RFC状态一样，这保留了搜索“ function foo”的可能性，而无需进行任何必要的正则表达式修改。 而且，这与HHVM的用法一致，因此这是额外的意外兼容性奖励。
Others complained about the “strictification” of PHP, but as one commenter states, you really find the value of this when you start coding against interfaces or inheriting other people’s code. Besides, as long as it’s optional and its existence does not in any way affect PHP’s general performance or stability, there’s no harm in it. Complaining about it is, to me, akin to complaining about OOP being added to PHP when procedural spaghetti worked so well for most cases back then. Languages evolve, and this is a step in the right direction.
其他人则抱怨PHP的“限制性”，但是正如一位评论者所言，当您开始针对接口进行编码或继承其他人的代码时，您确实会发现PHP的价值。 此外，只要它是可选的并且它的存在不以任何方式影响PHP的总体性能或稳定性，就不会有任何害处。 对我来说，对此进行抱怨就像是抱怨说，当程序面条在大多数情况下都非常有效时，将OOP添加到PHP中时。 语言在不断发展，这是朝正确方向迈出的一步。
What do you think?
你怎么看？
The upcoming version proposes to remove PHP4 style constructors (yet to be voted on). You can read what this means in the RFC, it’s simple and would be futile to repeat it here – but what’s actually very interesting is the mental anguish such a move seems to be causing some people. For example, this. “Please do not break our language”, pleads Tony, who seems intent on using its broken features.
即将发布的版本建议删除PHP4样式的构造函数 (尚待表决)。 您可以阅读RFC中的含义，这很简单，在这里重复一遍是徒劳的-但实际上非常有趣的是，这种举动似乎引起了某些人的心理痛苦。 例如， this 。 “请不要破坏我们的语言” ，托尼恳求说，他似乎打算使用其破坏性功能。
The post is well written despite the obvious anger, but it makes me wonder – if you’ve kept such a codebase alive for so long, is there really a need to upgrade to PHP 7? And if there is a need to upgrade to PHP 7, is it not easier to simply hunt down the offending classes and fix their constructors? Surely this is something you can delegate to juniors, given enough unit tests in your code base to make sure it all goes well? And if you don’t have unit tests, if your app is a mess, do you really hope to benefit in any way from moving to PHP 7? Wouldn’t you be better off Modernizing your Application first?
尽管有明显的愤怒，该帖子写得很好，但是让我怀疑–如果您将这样的代码库保存了这么长时间，是否真的需要升级到PHP 7？ 如果有必要升级到PHP 7，是不是更容易简单地追捕违规类和修复它们的构造？ 如果在代码库中进行了足够的单元测试以确保一切正常，那么您可以肯定将这委派给初级用户吗？ 而且，如果您没有单元测试，并且您的应用程序一团糟，那么您真的希望以任何方式从迁移到PHP 7中受益吗？ 首先，对您的应用程序进行现代化升级会更好吗？
The sentence “This means that code which I wrote 10 years ago should still run today, and should still run 10 years from now.” is, to me, madness – you definitely and absolutely should not expect this of ANY language across major versions. To draw a parallel from the real world, you shouldn’t expect to be allowed to own slaves today just because a law from long ago said you could. Yes, the BC break came after a bloody revolution, but when most slaveowners repented or died, there was peace.
句子“这意味着我10年前编写的代码应仍在今天运行，并且应在现在10年后运行。” 对我而言，这是疯狂的事–您绝对绝对不应在主要版本中期望任何语言。 为了与现实世界相提并论，不应仅仅因为很久以前的一项法律就可以允许今天拥有奴隶。 是的，卑诗省的破灭是在一场血腥的革命之后发生的，但是当大多数奴隶主悔改或死去时，就和平了。
Granted, Tony is right in that it would take effort to remove the feature, while it would take none to leave it in. But in the long run, it will take more collective effort to fix the problems these constructors sometimes cause, than to remove it right now.
诚然，Tony是对的，因为删除该功能将花费很多精力，而将其保留下来则不需要花费任何精力。但是从长远来看，与删除这些构造函数有时会引起的问题相比，将需要更多的集体努力来解决。现在。
Understandably, BC breaks always upset some people, even if major versions are perfectly okay having BC breaks for the purpose of progress. But imagine the fervor when such people find out about this. Heck, imagine what would have happened if WordPress hadn’t stepped into 2001 last year and updated to mysqli instead of mysql – either no WP installation would work on PHP 7, or PHP 7 would keep an unsafe and long deprecated feature for the sole reason of keeping WP users happy.
可以理解，即使主要版本完全可以让BC中断以达到进步的目的，但BC中断总是使某些人感到不安。 但是，当这样的人发现这一点时，请想象一下这种热情。 哎呀，想象一下，如果WordPress去年没有进入2001年并更新为mysqli而不是mysql ，将会发生什么情况–要么WP安装都无法在PHP 7上运行，要么PHP 7会保留一个不安全且长期不推荐使用的功能，这是唯一的原因让WP用户感到高兴。
My advice to those fearing PHP 7 is – stop. If you don’t want to upgrade, don’t. If you could be on 5.3 or 5.2 for so long (looking at you, CodeIgniter), you can be on 5.6 for another decade – but let us have modern PHP. Leave progress up to those who are willing to accept it.
我对那些担心PHP 7的人的建议是–停止。 如果您不想升级，请不要。 如果您使用5.3或5.2这么长时间(对您来说，CodeIgniter)，您可以再使用5.6十年，但是让我们拥有现代PHP。 将进度留给愿意接受的人。
What say you? Is this removal of artifacts nonsense or needed?
你说什么 这是对废品的废话吗？
As an interesting sidenote, there are some changes in PHP 7 that might actually cause a bit of a delay with extension porting to version 7. The API for building PHP extensions is still under a revamping (read: cleaning) process and all is subject to change – nonetheless, this provocative tweet from Sara Golemon gathered quite a bit of attention.
作为一个有趣的旁注，PHP 7中的某些更改实际上可能会导致扩展移植到版本7时出现一些延迟。用于构建PHP扩展的API仍处于改进(阅读：清除)过程中，所有内容均受制于此。变化–尽管如此，萨拉·高蒙(Sara Golemon)的这则挑衅性推文吸引了相当多的关注。
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.
该死的。 PHP7扩展API更改有一些严重的意外之处。 没什么，但是现在是切换到HHVM的好时机。
— SaraMG (@SaraMG) January 3, 2015
— SaraMG(@SaraMG) 2015年1月3日
She basically says the changes in extension development from 5.6 to 7 will be so great, you might as well learn how to make HHVM extensions. She then proceeded to craft a lengthy series on that exact topic, explaining in depth and on examples how to create an HHVM extension.
她基本上说，扩展开发从5.6到7的变化将是如此巨大，您不妨学习如何进行HHVM扩展。 然后，她着手就该确切主题编写了冗长的系列文章，深入解释了如何创建HHVM扩展的示例。
Do you develop extensions? Did you study the changes, or do you feel like it’s still too early to tell if they’ll have an effect?
您是否开发扩展程序？ 您是否研究了这些更改，或者您认为判断它们是否会产生效果还为时过早？
Edit: It has been brought to my attention that Sara has later started documenting a new extension API compatible with both HHVM and PHP 7. We could – it seems – have extensions compatible with both runtimes!
编辑：引起我注意的是Sara后来开始记录与HHVM和PHP 7兼容的新扩展API。我们-似乎-具有与两个运行时兼容的扩展！
As usual, there’s no shortage of drama in PHP land. Like all major revolutions throughout history, the PHP 7 revolution will also be spilling some blood before producing something awesome. PHP 7 is still a long way off, so even if you’re caught in the crossfire of musket shots, there’s ample time to get to cover. Unless you’ve been sleeping under tank tracks, then there’s little either side can do to help you.
和往常一样，PHP领域不乏戏剧性。 像历史上所有重大革命一样，PHP 7革命也将在产生令人敬畏的东西之前洒一些血。 PHP 7还有很长的路要走，因此，即使您陷入步枪射击的交火中，也有足够的时间来解决这个问题。 除非您一直在坦克轨道下睡觉，否则任何一方都无法帮助您。
What do you think of these RFCs? How do you feel about PHP 7 in general? Is it heading in the direction you’d like it to head in? Let us know – we want to hear your thoughts!
您如何看待这些RFC？ 您对PHP 7总体感觉如何？ 它正在朝您想要的方向前进吗？ 让我们知道–我们想听听您的想法！
翻译自: https://www.sitepoint.com/php-7-revolution-return-types-removed-artifacts/
相关资源：systemd.software：https：systemd.software的存储库-源码