rfc:reserve_primitives

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
rfc:reserve_primitives [2015/02/08 11:49] thekidrfc:reserve_primitives [2017/09/22 13:28] (current) – external edit 127.0.0.1
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 42: Line 42:
 The options this RFC suggests discussing are: The options this RFC suggests discussing are:
  
-====== Option 1: Reserve ======+==== Option 1: Reserve ====
 This first option suggests reserving primitive type names. This first option suggests reserving primitive type names.
  
Line 49: Line 49:
   * BC break: No class, interface or trait named after a primitive name can be imported with ''use''   * BC break: No class, interface or trait named after a primitive name can be imported with ''use''
  
-====== Option 2: Allow namespaced ======+==== Option 2: Allow namespaced ====
 This second option suggests allowing primitive type names in combination with namespaces, but disallowing them in global scope. This second option suggests allowing primitive type names in combination with namespaces, but disallowing them in global scope.
  
Line 66: Line 66:
 </PHP> </PHP>
  
-====== Option 3: Allow namespaces and use ======+==== Option 3: Allow namespaces and use ====
 This would allow primitive type names in combination with namespaces, and accept imports, overriding primitive definitions. This would allow primitive type names in combination with namespaces, and accept imports, overriding primitive definitions.
  
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 97: Line 97:
 </PHP> </PHP>
  
-====== Option 5: Use cast-tokens ======+==== Option 5: Use cast-tokens ====
 This would make any situation unambigous, reuse already existing parser tokens, and create no BC breaks: This would make any situation unambigous, reuse already existing parser tokens, and create no BC breaks:
  
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 ====
 The type names would not be reserved. No BC breaks occur, while it's also not possible to use them for parameter and return type hints. For both situations, alternative suggestions, e.g. along a "design by contract" RFC are discussed. The type names would not be reserved. No BC breaks occur, while it's also not possible to use them for parameter and return type hints. For both situations, alternative suggestions, e.g. along a "design by contract" RFC are discussed.
  
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.1423396195.txt.gz · Last modified: 2017/09/22 13:28 (external edit)