Table of Contents

RFC: Merge Symbol Tables

Introduction

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.

Proposal

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.

Benefits

TODO

Backward Incompatible Changes

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

Proposed PHP Version(s)

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.

RFC Impact

To Existing Extensions

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.

To Opcache

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

Open Issues

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

Future Scope

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

Proposed Voting Choices

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

Patches and Tests

At this stage there is no patch.

References

Links to external references, discussions or RFCs