merge_member_symbol_tables

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/05/29 19:30	current
Line 1:	Line 1:
	+	====== 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

	+	===== 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:
	+
	+	<PHP>
	+	class Foo {
	+	const bar = 'constant';
	+	public static $bar = 'property';
	+	public static function bar() {
	+	return 'method';
	+	}
	+	}
	+	</PHP>
	+
	+	In order to disambiguate between them we have different syntax:
	+
	+	<PHP>
	+	var_dump(Foo::bar);
	+	var_dump(Foo::$bar);
	+	var_dump(Foo::bar());
	+	</PHP>
	+
	+	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

merge_symbol_tables

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2017/09/22 13:28		current
Line 7:		Line 7:

	===== Introduction =====		===== Introduction =====
-	Currently a class can have constants, properties and methods thatshare a name. Constants are case sensitive while properties and functions are insensitive. This causes various syntactic and issues.	+	Currently we have symbol tables separate from each other based on kind. For instance, constants, functions, and classes/interfaces/traits all have their own tables. This allows us to use the same name for a constant, function, and a class all simultaneously:
-		+
-	For example, this class has ''$bar'' as both a property and a method:	+

	<PHP>		<PHP>
-	class Foo {	+	const Symbol = 'symbol';
-	const bar = 'constant';	+	function symbol() {}
-	public static $bar = 'property';	+	class Symbol {}
-	public static function bar() {	+	// no errors
-	return 'method';	+
-	}	+
-	}	+
	</PHP>		</PHP>

-	In order to disambiguate between them we have different syntax:	+	This behavior is sometimes useful but prohibits other, more useful features such as the ability to use a function name as a callback without using strings:

	<PHP>		<PHP>
-	var_dump(Foo::bar);	+	// this looks for constant strlen, not function strlen:
-	var_dump(Foo::$bar);	+	array_map(strlen, ['hello', 'world']);
-	var_dump(Foo::bar());	+
		+	// must use the string:
		+	array_map('strlen', ['hello', 'world']);
	</PHP>		</PHP>

-	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.	+	This makes it difficult to rename functions because it is more difficult to determine if a string is meant to be the function name or not compared to a symbolic usage. This RFC proposes to unify the constant, function, and class/interface/trait symbol tables into one.
-		+
-	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 =====		===== 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.	+	This RFC proposes to unify the constant, function, and class/interface/trait symbol tables into one.

	===== Benefits =====		===== Benefits =====
Line 42:		Line 35:

	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====
-	Any file that contains a class with methods, constants or properties that share the same identifier will suddenly fail to parse.	+	Any projects currently using the same name for different kinds of symbols will now get a redefinition error.

	===== Proposed PHP Version(s) =====		===== 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.	+	This RFC targets PHP 8.0 or PHP 9.0 because of the backwards compatibility breaks.

	===== RFC Impact =====		===== RFC Impact =====
	==== To Existing Extensions ====		==== 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.	+	TODO

	==== To Opcache ====		==== To Opcache ====
Line 55:		Line 48:

	===== Open Issues =====		===== Open Issues =====
-	Constants are currently case sensitive while methods and properties are case insensitive. Should we unify the case sensitivity at the same time?	+	Constants are currently case sensitive while functions and classes are case insensitive. Should we unify the case sensitivity at the same time?

	===== Future Scope =====		===== Future Scope =====

PHP Wiki - rfc:php8

merge_member_symbol_tables

merge_symbol_tables