rfc:reserve_primitives

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:reserve_primitives [2015/02/08 11:53]
thekid Formatting
rfc:reserve_primitives [2017/09/22 13:28] (current)
Line 9: Line 9:
  
 ===== Introduction ===== ===== Introduction =====
-Reserving the names as suggested e.g. by the [[https://​wiki.php.net/​rfc/​scalar_type_hints|scalar types hints RFC]] will create problems if people have used them as class, interface or trait names.+Reserving the names as suggested e.g. by the [[https://​wiki.php.net/​rfc/​scalar_type_hints|scalar types hints RFC]] will create problems if people have used them as class, interface or trait names. Creating BC problems slows adoption, so they should be outweighed with benefits.
  
 ===== Proposal ===== ===== Proposal =====
Line 86: Line 86:
 To the reader, it's *probably* clear because of the uppercasing. If a lowercase class was used, this would be confusing. Looking at real-life frameworks and libraries, we'd usually find the first case. To the reader, it's *probably* clear because of the uppercasing. If a lowercase class was used, this would be confusing. Looking at real-life frameworks and libraries, we'd usually find the first case.
  
-==== Option 4: Case insensitivity ====+==== Option 4: Case insensitivity ​exception ​====
 This option would add special handling to the primitive types names and allow all situations in which a different casing was used. This option would add special handling to the primitive types names and allow all situations in which a different casing was used.
  
Line 110: Line 110:
 </​PHP>​ </​PHP>​
  
-Fair enough, this is counter-intuitive to all other types.+Fair enough, this is counter-intuitive to the syntax used so far for arrays and callables as well as for value types; and the majority of other programming languages.
  
 ==== Option 6: Do not reserve ==== ==== Option 6: Do not reserve ====
Line 120: Line 120:
 ===== RFC Impact ===== ===== RFC Impact =====
 In all situations except the last two options, reserving primitive type names causes a BC break. The options above sketch out how we can cope with this, balancing the usefulness of being able to use these tokens and backwards compatibility on the other side. In all situations except the last two options, reserving primitive type names causes a BC break. The options above sketch out how we can cope with this, balancing the usefulness of being able to use these tokens and backwards compatibility on the other side.
 +
 +These frameworks would be affected by reserving the word "​string"​ (incomplete list):
 +
 +  * CakePHP - ''​lib/​Cake/​Utility/​String.php''​
 +  * Joomla - ''​src/​Joomla/​Filesystem/​Stream/​String.php''​
 +  * ZF2 - ''​library/​Zend/​XmlRpc/​Value/​String.php''​
 +  * Drupal8 - ''​core/​lib/​Drupal/​Component/​Utility/​String.php''​
 +  * XP Framework - ''​src/​main/​php/​lang/​types/​String.class.php''​
 +
 +This [[https://​searchcode.com/?​q=class+String&​lan=24|code search for a PHP String class]] suggests various more libraries will be affected. Same goes for "​Boolean",​ "​Integer",​ "​Int",​ "​Float"​ and "​Double"​
  
 ===== Future Scope ===== ===== Future Scope =====
Line 134: Line 144:
  
 ===== References ===== ===== References =====
-https://​wiki.php.net/​rfc/​scalar_type_hints+  * https://​wiki.php.net/​rfc/​scalar_type_hints 
 +  * https://​wiki.php.net/​rfc/​scalar_type_hints_v_0_1#​open_issues (Discussion about reserving names)
  
 ===== Rejected Features ===== ===== Rejected Features =====
 (TODO) (TODO)
rfc/reserve_primitives.1423396382.txt.gz · Last modified: 2017/09/22 13:28 (external edit)