rfc:class_and_interface_name_types

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
rfc:class_and_interface_name_types [2017/04/29 14:47] – expand ajfrfc:class_and_interface_name_types [2017/05/05 16:21] – revert accidental garbage ajf
Line 16: Line 16:
   - If the value is not a string, reject it.   - If the value is not a string, reject it.
   - If there is no currently-loaded class, interface, or trait with the name given by the value, attempt to autoload it.   - If there is no currently-loaded class, interface, or trait with the name given by the value, attempt to autoload it.
-  - If there is now no currently-loaded class or interface (as appropriate) with the name given by the value, reject the value.+  - If there is now no currently-loaded class or interface with the name given by the value, reject the value.
   - Otherwise, accept the value.   - Otherwise, accept the value.
 +
 +As a parameter type, it would permit default values of <php>NULL</php> (to make the parameter null) and constant strings (including <php>::class</php> syntax).
  
 A simple example of usage: A simple example of usage:
Line 24: Line 26:
 <?php <?php
  
-function accepts_class(class $class) {+function accepts_class(class $class = stdClass::class) {
     var_dump($class);     var_dump($class);
 } }
  
-accepts_class(stdClass::class);    // works +accepts_class();                   // string(8) "stdClass" 
-accepts_class("stdClass");         // also works +accepts_class(stdClass::class);    // string(8) "stdClass" 
-accepts_class(ArrayAccess::class); // interfaces are also accepted+accepts_class("stdClass");         // string(8) "stdClass" 
 +accepts_class(ArrayAccess::class); // string(11) "ArrayAccess"
 accepts_class("nonexistant");      // Fatal error: Uncaught TypeError: Argument 1 passed to accepts_class() must be of the type class, string given… accepts_class("nonexistant");      // Fatal error: Uncaught TypeError: Argument 1 passed to accepts_class() must be of the type class, string given…
 </code> </code>
Line 46: Line 49:
   * It resembles the <php>::class</php> syntax for obtaining the name of a class   * It resembles the <php>::class</php> syntax for obtaining the name of a class
   * It avoids the redundancy of saying "name", given PHP does not represent classes as values in any other way (excepting reflection)   * It avoids the redundancy of saying "name", given PHP does not represent classes as values in any other way (excepting reflection)
-  * It aligns with how PHP treats class and its fully-qualified name the same in several places (e.g. <php>new $class</php> and <php>$class::$property</php>)+  * It aligns with how PHP treats class and its fully-qualified name the same in several places (e.g. <php>new $class</php> and <php>$class::$property</php>)
  
 However, there are also arguments in favour of ''classname'': However, there are also arguments in favour of ''classname'':
Line 61: Line 64:
   * It limits the number of new types that are introduced (one versus two or three)   * It limits the number of new types that are introduced (one versus two or three)
   * It aligns with the internal ''zend_parse_parameters()'' type ''"C"'', used by some functions in the PHP standard library, which likewise accepts both class and interface names   * It aligns with the internal ''zend_parse_parameters()'' type ''"C"'', used by some functions in the PHP standard library, which likewise accepts both class and interface names
 +  * It aligns with how <php>::class</php> works for both class and interface names
   * Interfaces are essentially glorified abstract classes   * Interfaces are essentially glorified abstract classes
   * PHP internally represents interfaces as a kind of class   * PHP internally represents interfaces as a kind of class
Line 72: Line 76:
   * It might be surprising to see the name of an //interface// be passed as an argument to a parameter typed "<php>class</php>"   * It might be surprising to see the name of an //interface// be passed as an argument to a parameter typed "<php>class</php>"
  
-There is an advantages to a separate <php>interface</php> type, insofar as having PHP distinguish classes and interfaces in type declarations makes for clearer function signatures and avoids potential manual testing of whether a value is class or an interface.+There is an advantage to a separate <php>interface</php> type, insofar as having PHP distinguish classes and interfaces in type declarations makes for clearer function signatures and avoids potential manual testing of whether a value is class or an interface.
  
-If there was a separate <php>interface</php> type, there would be an argument for having the <php>class</php> type still also accept classes, since classes are a superset of interfaces, and classes can subclass (“implement”) interfaces, but not the other way around.+If there was a separate <php>interface</php> type, there would be an argument for having the <php>class</php> type also accept interfaces, since classes are a superset of interfaces, and classes can subclass (“implement”) interfaces, but not the other way around.
  
 If none of these approaches are palatable, there could be a //third// type accepting both classes and interfaces, perhaps named ''classlike''. However, this might be reaching the point of diminishing returns. If none of these approaches are palatable, there could be a //third// type accepting both classes and interfaces, perhaps named ''classlike''. However, this might be reaching the point of diminishing returns.
Line 104: Line 108:
 There is a patch here which contains tests: https://github.com/php/php-src/compare/master...hikari-no-yume:class_type_declaration There is a patch here which contains tests: https://github.com/php/php-src/compare/master...hikari-no-yume:class_type_declaration
  
-It does not yet handle inheritance concerns.+The commits for versions with multiple new types do not handle inheritance concerns.
  
 There is not yet a pull request. There is not yet a pull request.
rfc/class_and_interface_name_types.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1