编译器代码表明这是设计使然，尽管我不知道其背后的官方推理是什么。我也不确定要可靠地实现此功能需要付出多少努力，但目前的完成方式肯定存在一些限制。
虽然我对 PHP 编译器的了解并不广泛，但我将尝试说明我认为发生了什么，以便您了解问题所在。您的代码示例非常适合此过程，因此我们将使用它：
class Foo {
public $path = array(
realpath(".")
);
}
如您所知，这会导致语法错误。这是PHP grammar 的结果，其相关定义如下：
class_variable_declaration:
//...
| T_VARIABLE '=' static_scalar //...
;
因此，在定义$path等变量的值时，期望值必须与静态标量的定义相匹配。不出所料，这有点用词不当，因为静态标量的定义还包括其值也是静态标量的数组类型：
static_scalar: /* compile-time evaluated scalars */
//...
| T_ARRAY '(' static_array_pair_list ')' // ...
//...
;
让我们假设语法不同，并且类变量声明规则中的注释行看起来更像以下内容，它将与您的代码示例匹配（尽管破坏了其他有效的分配）：
class_variable_declaration:
//...
| T_VARIABLE '=' T_ARRAY '(' array_pair_list ')' // ...
;
重新编译 PHP 后，示例脚本将不再因语法错误而失败。相反，它会因编译时错误“无效的绑定类型”而失败。由于代码现在基于语法是有效的，这表明实际上在编译器的设计中存在某些特定的东西导致了问题。为了弄清楚那是什么，让我们暂时回到原来的语法，假设代码示例有一个有效的 $path = array( 2 ); 赋值。
使用语法作为指导，在解析此代码示例时，可以遍历compiler code 中调用的操作。我省略了一些不太重要的部分，但过程看起来像这样：
// ...
// Begins the class declaration
zend_do_begin_class_declaration(znode, "Foo", znode);
// Set some modifiers on the current znode...
// ...
// Create the array
array_init(znode);
// Add the value we specified
zend_do_add_static_array_element(znode, NULL, 2);
// Declare the property as a member of the class
zend_do_declare_property('$path', znode);
// End the class declaration
zend_do_end_class_declaration(znode, "Foo");
// ...
zend_do_early_binding();
// ...
zend_do_end_compilation();
虽然编译器在这些不同的方法中做了很多工作，但需要注意一些事项。
- 对
zend_do_begin_class_declaration() 的调用会导致对get_next_op() 的调用。这意味着它将新的操作码添加到当前操作码数组中。
-
array_init() 和 zend_do_add_static_array_element() 不会生成新的操作码。相反，该数组会立即创建并添加到当前类的属性表中。方法声明以类似的方式工作，通过 zend_do_begin_function_declaration() 中的一个特殊情况。
-
zend_do_early_binding() 消耗当前操作码数组的最后一个操作码，在将其设置为 NOP 之前检查以下类型之一：
- ZEND_DECLARE_FUNCTION
- ZEND_DECLARE_CLASS
- ZEND_DECLARE_INHERITED_CLASS
- ZEND_VERIFY_ABSTRACT_CLASS
- ZEND_ADD_INTERFACE
请注意，在最后一种情况下，如果操作码类型不是预期的类型之一，则会引发错误 - “无效绑定类型” 错误。由此，我们可以看出，允许以某种方式分配非静态值会导致最后一个操作码与预期不同。那么，当我们使用经过修改的语法的非静态数组时会发生什么？
编译器不调用array_init()，而是准备参数并调用zend_do_init_array()。这反过来又调用get_next_op() 并添加一个新的INIT_ARRAY opcode，产生如下内容：
DECLARE_CLASS 'Foo'
SEND_VAL '.'
DO_FCALL 'realpath'
INIT_ARRAY
这就是问题的根源。通过添加这些操作码，zend_do_early_binding() 会获得意外输入并引发异常。由于早期绑定类和函数定义的过程似乎是 PHP 编译过程不可或缺的一部分，因此不能忽略它（尽管 DECLARE_CLASS 生产/消费有点混乱）。同样，尝试内联评估这些额外的操作码是不切实际的（您无法确定给定的函数或类是否已被解析），因此无法避免生成操作码。
一个潜在的解决方案是构建一个新的操作码数组，该数组的范围为类变量声明，类似于处理方法定义的方式。这样做的问题是决定何时评估这种一次性序列。是否会在加载包含该类的文件时、首次访问属性时或构造该类型的对象时完成？
正如您所指出的，其他动态语言已经找到了处理这种情况的方法，因此做出该决定并使其发挥作用并非不可能。不过据我所知，在 PHP 的情况下这样做不会是单行修复，而且语言设计者似乎已经决定在这一点上不值得包含它。