PHP RFC:保留更多的类型在PHP 7中要求在类，接口和trait的名称和命名空间上下文中保留以下词:resource, object, mixed和numeric。
但是，下面的代码在PHP 7中是有效的。
class resource {}
class object {}
class mixed {}
class numeric {}
我想把我的接口命名为Resource，但如果PHP在PHP 7发布流中突然把它变成保留字，我会很讨厌的。
- 鉴于可接受的PR与此处提交的经验证据之间存在明显的冲突，并且在源代码中没有任何此类保留，我是否可以安全地将我的接口称为
Resource? php7中还会有这个PR的补丁吗?还是现在必须等到PHP-next? - 没有任何实施承诺是否表明它可能永远不会在未来的任何版本中实施?
编辑:根据随后的讨论，强调这些词只是软保留，似乎还有一个关键问题要问。在我看来，一个词要么应该保留，要么不应该保留，而软保留状态没有意义，因此:
- 为什么要创建软保留状态而不是"硬"保留这些词?
但是如果PHP在PHP 7发布流中突然把它作为保留字，我会很讨厌的。
好吧，以你所拥有的知识，把它命名为资源是愚蠢的，碰碰运气。
鉴于可接受的PR与此处提交的经验证据之间存在明显的冲突，并且在源代码中没有任何此类保留，我是否可以安全地将我的接口称为Resource ?
。除非你确定它再次出现在桌子上，否则这将是非常愚蠢的。
这个PR的补丁在PHP 7中还能实现吗?还是现在必须等到PHP-next?
根据我们的手册，它们目前是软保留的:
Soft reserved words
resource (as of PHP 7) object (as of PHP 7) mixed (as of PHP 7) numeric (as of PHP 7)
它们是否真的是硬保留并不重要。
没有任何实现它的承诺是否表明它可能永远不会在未来的任何版本中实现?
没有人有水晶球。没有人能告诉你未来的版本会发生什么。
为什么创建软保留状态而不是"硬"保留这些单词?
因为这可能是一个相当大的BC断点。当弃用旧的mysql_* API时也发生了同样的情况。这样一来，每个人都可以提前知道在它成为问题之前不要使用它。
"软保留"的目的是给您时间来修复您的代码。这允许您现在就升级到PHP 7，而不是让您首先找到这些关键字的所有用法并修复它们。但是你被警告你应该修复它们，因为未来的更新可能会破坏你的代码。
这与不推荐计划在将来删除的特性的原因相似。
至于为什么他们选择硬保留一些词而软保留另一些词，可能是因为他们知道有很多网站使用后者，所以立即保留它们会使许多网站更难升级。