rfc:reserve_primitives
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:reserve_primitives [2015/02/08 11:48] – created thekid | rfc:reserve_primitives [2015/02/08 17:05] – thekid | ||
---|---|---|---|
Line 9: | Line 9: | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | Reserving the names as suggested e.g. by the [[https:// | + | Reserving the names as suggested e.g. by the [[https:// |
===== Proposal ===== | ===== Proposal ===== | ||
Line 42: | Line 42: | ||
The options this RFC suggests discussing are: | The options this RFC suggests discussing are: | ||
- | ===== 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 '' | * BC break: No class, interface or trait named after a primitive name can be imported with '' | ||
- | ===== 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: | ||
</ | </ | ||
- | ===== 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. | ||
- | ===== Case insensitivity | + | ==== Option 4: Case insensitivity |
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: | ||
</ | </ | ||
- | ===== 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: | ||
</ | </ | ||
- | 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. |
- | ===== 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, | 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, | ||
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 (incomplete list): | ||
+ | |||
+ | * CakePHP - '' | ||
+ | * Joomla - '' | ||
+ | * ZF2 - '' | ||
+ | * Drupal8 - '' | ||
+ | * XP Frameworrk - '' | ||
+ | |||
+ | This [[https:// | ||
===== Future Scope ===== | ===== Future Scope ===== | ||
Line 134: | Line 144: | ||
===== References ===== | ===== References ===== | ||
- | https:// | + | * https:// |
+ | * https:// | ||
===== Rejected Features ===== | ===== Rejected Features ===== | ||
(TODO) | (TODO) |
rfc/reserve_primitives.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1