rfc:safe_cast
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:safe_cast [2014/11/12 17:08] – __toString clarity ajf | rfc:safe_cast [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== PHP RFC: Safe Casting Functions ====== | ====== PHP RFC: Safe Casting Functions ====== | ||
- | * Version: 0.1.4 | + | * Version: 0.1.8 |
- | * Date: 2014-10-20, Last Updated 2014-11-12 | + | * Date: 2014-10-20, Last Updated 2014-11-14 |
* Author: Andrea Faulds, ajf@ajf.me | * Author: Andrea Faulds, ajf@ajf.me | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
Line 9: | Line 9: | ||
Currently, PHP only provides one means of type conversion: explicit casts. These casts never fail or emit errors, making them dangerous to use, as when passed garbage input, they will simply return garbage instead of indicating that something went wrong. This makes it difficult to write robust applications which handle user data. They also prevent any suggestion of strict type hinting for scalar types, because if that were to be added, users would simply use dangerous explicit casts to get around errors and the result would be code that is buggier than it would have been without type hinting at all. | Currently, PHP only provides one means of type conversion: explicit casts. These casts never fail or emit errors, making them dangerous to use, as when passed garbage input, they will simply return garbage instead of indicating that something went wrong. This makes it difficult to write robust applications which handle user data. They also prevent any suggestion of strict type hinting for scalar types, because if that were to be added, users would simply use dangerous explicit casts to get around errors and the result would be code that is buggier than it would have been without type hinting at all. | ||
+ | |||
+ | For int and float conversion specifically, | ||
===== Proposal ===== | ===== Proposal ===== | ||
- | A set of three "safe casting" | + | Two families |
+ | |||
+ | '' | ||
- | '' | + | '' |
- | '' | + | '' |
- | '' | + | The new class '' |
==== Rationale ==== | ==== Rationale ==== | ||
Line 24: | Line 28: | ||
The concept was developed in my thoughts, and in discussions with Anthony Ferrara (both in-person at PHPNW14 and online) and others in [[http:// | The concept was developed in my thoughts, and in discussions with Anthony Ferrara (both in-person at PHPNW14 and online) and others in [[http:// | ||
- | * The functions | + | * The functions |
- | * Floats | + | * Whitespace is not allowed because it is expected that most input will lack it, and it can be easily stripped before conversion using '' |
- | * Objects with '' | + | * Generally, no data is allowed to be lost, with the exception of floats, which are allowed to lose accuracy from their decimal representations. This is because zero data-loss is impossible |
- | * '' | + | * Leading zeros are not accepted for '' |
- | * '' | + | * There are two sets of functions, one that returns |
- | * The functions | + | * In some cases, invalid input is an exceptional case, so an exception is desirable, but in other cases, it is not exceptional, so an exception shouldn' |
- | * If strict type hinting were added, they would fail for a nullable typehint | + | * It is often repeated that exceptions shouldn't be used for flow control. |
- | * '' | + | * It is PHP tradition |
- | * '' | + | * This placates both people who would like an error return value, and people who would like exceptions. |
- | * An error return value was chosen instead of an exception: | + | * Return values |
- | * To make chaining easier, and because checking for FALSE is easier than checking if an exception was thrown ('' | + | * Checking |
- | * Exceptions | + | |
- | * The cast failing is not an exceptional case, as it is a validation function, so it should use a return value, not an exception | + | |
- | * Catching | + | |
==== Examples Table ==== | ==== Examples Table ==== | ||
Line 43: | Line 44: | ||
A sample table of whether values pass or fail generated by [[https:// | A sample table of whether values pass or fail generated by [[https:// | ||
- | ^ value | + | ^ value |
^ string(6) " | ^ string(6) " | ||
+ | ^ string(0) "" | ||
^ string(1) " | ^ string(1) " | ||
^ int(0) | ^ int(0) | ||
Line 50: | Line 52: | ||
^ string(2) " | ^ string(2) " | ||
^ string(3) " | ^ string(3) " | ||
- | ^ string(3) " | + | ^ string(3) " |
^ string(3) " | ^ string(3) " | ||
^ int(10) | ^ int(10) | ||
Line 92: | Line 94: | ||
===== Open Issues ===== | ===== Open Issues ===== | ||
- | While I'd prefer to return FALSE on error, it would also be possible to return NULL or raise an exception. As this seems to be relatively controversial, | + | None. |
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== | ||
Line 100: | Line 102: | ||
===== Future Scope ===== | ===== Future Scope ===== | ||
- | This might be extended to other types. However, support for the other scalar types has deliberately not been included. For booleans, there is no clear single format to accept, | + | This might be extended to other types. However, support for the other scalar types has deliberately not been included. For booleans, there is no clear single format to accept, |
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
Line 106: | Line 108: | ||
As this is not a language change and only introduces new functions, only a 50%+1 majority will be required. The vote will be a straight Yes/No vote on accepting the RFC and merging the patch into master. | As this is not a language change and only introduces new functions, only a 50%+1 majority will be required. The vote will be a straight Yes/No vote on accepting the RFC and merging the patch into master. | ||
- | Because the behaviour on the error case is controversial, | + | ==== Vote ==== |
+ | |||
+ | Voting opened 2014-11-19 and ended 2014-11-29. | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
===== Patches and Tests ===== | ===== Patches and Tests ===== | ||
Line 132: | Line 141: | ||
===== Changelog ===== | ===== Changelog ===== | ||
+ | * v0.1.8 - ext/filter note in Introduction | ||
+ | * v0.1.7 - Allow positive signs | ||
+ | * v0.1.6 - Dropped zero round trip data loss principle, added octal and whitespace rationale | ||
+ | * v0.1.5 - Renamed '' | ||
* v0.1.4 - Reject leading ' | * v0.1.4 - Reject leading ' | ||
* v0.1.3 - Return NULL, don't include exceptions in vote | * v0.1.3 - Return NULL, don't include exceptions in vote | ||
* v0.1.2 - Leading and trailing whitespace is not permitted | * v0.1.2 - Leading and trailing whitespace is not permitted | ||
* v0.1.1 - Rationale | * v0.1.1 - Rationale | ||
- | * v0.1 - Crated | + | * v0.1 - Created |
rfc/safe_cast.1415812107.txt.gz · Last modified: 2017/09/22 13:28 (external edit)