rfc:class_name_literal_on_object

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
rfc:class_name_literal_on_object [2020/01/09 10:24] – created nikicrfc:class_name_literal_on_object [2020/02/17 10:51] (current) nikic
Line 3: Line 3:
   * Author: Nikita Popov <nikic@php.net>   * Author: Nikita Popov <nikic@php.net>
   * Target Version: PHP 8.0   * Target Version: PHP 8.0
-  * Status: Under Discussion+  * Status: Implemented
   * Implementation: https://github.com/php/php-src/pull/5065   * Implementation: https://github.com/php/php-src/pull/5065
  
 ===== Introduction ===== ===== Introduction =====
  
-The ''Foo\Bar::class'' syntax has been introduced in PHP 5.5 to allow fetching a class name as a string, in a way that respects context-dependent name resolution rules and is understood by IDEs. As it is syntactically similar to a class constant acccess, programmers intuitively expect the syntax ''$object::class'' to work as well and provide the same result as ''get_class($object)''. This RFC proposes to allow that syntax.+The ''Foo\Bar::class'' syntax has been introduced in PHP 5.5 to allow fetching a class name as a string, in a way that respects context-dependent name resolution rules and is understood by IDEs. As it is syntactically similar to a class constant access, programmers intuitively expect the syntax ''$object::class'' to work as well and provide the same result as ''get_class($object)''. This RFC proposes to allow that syntax.
  
 The original rationale for not allowing the ''$object::class'' syntax was that ''Foo\Bar::class'' is resolved at compile-time, which is not possible for ''$object::class''. However, this premise is already incorrect for two cases: First, ''static::class'' is always resolved at runtime, equivalent to ''get_called_class()''. Second, ''self::class'' and ''parent::class'' are also sometimes resolved at runtime, for example in closures. The original rationale for not allowing the ''$object::class'' syntax was that ''Foo\Bar::class'' is resolved at compile-time, which is not possible for ''$object::class''. However, this premise is already incorrect for two cases: First, ''static::class'' is always resolved at runtime, equivalent to ''get_called_class()''. Second, ''self::class'' and ''parent::class'' are also sometimes resolved at runtime, for example in closures.
Line 28: Line 28:
 </PHP> </PHP>
  
-**Open Question:** Additionally, it would be possible to also allow ''$object'' to be stringin which case the string would be returned verbatimThis would be consistent with the ''$className::CONST_NAME'' syntax. I'm not sure whether we should do that, as I can't imagine a context in which this would be useful, and the fact that the class name is not validated or loaded might be more unexpected here than usual.+This RFC does not permit ''$object'' to be string and throws a ''TypeError'' in that case as wellIt would be possible to allow strings to be consistent with the ''$className::CONST_NAME'' syntax. In that case, ''$str::class'' would return ''$str'' verbatim. As this doesn't seem practically useful, and likely somewhat surprising (esp. the fact that the class name is not validated at all, and can contain characters not allowed in class names), this functionality is omitted.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 36: Line 36:
 ===== Vote ===== ===== Vote =====
  
-Yes/No.+Voting started 2020-01-28 and ends 2020-02-11. 
 + 
 +<doodle title="Allow ::class on objects?" auth="nikic" voteType="single" closed="true"> 
 +   Yes 
 +   No 
 +</doodle>
  
rfc/class_name_literal_on_object.1578565475.txt.gz · Last modified: 2020/01/09 10:24 by nikic