RFC: Merge Symbol Tables

• Version: 1.0
• Date: 2018-02-04
• Author: Levi Morrison levim@php.net
• Status: Draft
• First Published at: http://wiki.php.net/rfc/php8/merge_member_symbol_tables

Currently a class can have constants, properties and methods that share a name. Constants are case sensitive while properties and functions are insensitive. This causes various syntactic and issues.

For example, this class has $bar as both a property and a method:

class Foo {
    const bar = 'constant';
    public static $bar = 'property';
    public static function bar() {
        return 'method';
    }
}

In order to disambiguate between them we have different syntax:

var_dump(Foo::bar);
var_dump(Foo::$bar);
var_dump(Foo::bar());

However, in certain cases this causes issues. How do you access a constant dynamically? You can't do Foo::$bar because PHP thinks it is a static property and not a constant.

Another common problem is when you store a callable as a property. The syntax $this->$property() will evaluate to a dynamic method call, not a property retrieval which is then called.

This RFC will unify the tables, which allows the logical syntax to be reused without introducing ambiguity.

All class constants, properties and methods will logically share the same symbol table. Whenever a new constant, property or method is defined all tables will be checked to ensure that there is no existing conflict. If a conflict is found an error will be emitted. This strategy is based on the assumption that modifying the smallest amount of the engine is probably the best way forward. If we discover there are other benefits (perhaps in significantly reduced memory) we may unify the symbol tables.

TODO

Any file that contains a class with methods, constants or properties that share the same identifier will suddenly fail to parse.

This RFC targets PHP 8.0 because of the backwards compatibility concerns. Additionally it will take some time for PHP developers to prepare their codebase for a BC break of this magnitude.

Extensions may declare constants, properties or methods that share the same name. In some cases it is possible to prevent this from happening, but since objects are free to implement custom handlers it cannot be guaranteed. If extensions use such properties, constants or methods then at runtime they are invoking undefined behavior.

Depending on the exact implementation it may be possible for opcache to work without any changes.

Constants are currently case sensitive while methods and properties are case insensitive. Should we unify the case sensitivity at the same time?

This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC.

This RFC requires two-thirds of the votes to be in favor of logically unifying the symbol tables.

At this stage there is no patch.

Links to external references, discussions or RFCs