rfc:typechecking
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
rfc:typechecking [2009/07/03 20:47] – lsmith | rfc:typechecking [2013/02/13 21:15] – Removed return type hinting entry to withdrawn willfitch | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Request for Comments: | + | ===== Request for Comments: |
- | * Version: 0.1 | + | |
- | * Date: 2009-06-03 | + | |
- | * Author: Lukas Smith < | + | |
- | * Status: In draft stage | + | |
- | * First Published at: http:// | + | |
- | This RFC is provide a proposal | + | Various RFCs that have been proposed |
- | + | ||
- | ===== Introduction ===== | + | |
+ | === History === | ||
PHP is a [[http:// | PHP is a [[http:// | ||
- | Several people still have asked to expand this feature to cover other data types, which mostly ask for similar strict | + | * [[rfc: |
- | ===== Why is strict type checking problematic? | + | * [[rfc: |
- | + | * [[rfc: | |
- | Strict | + | |
- | + | * [[rfc:typecheckingparseronly|Parser and Reflection-API only Type Hints]] by Derick (Implemented) | |
- | Proponents of purely strict | + | |
- | + | ||
- | That is to define a variable that contains a boolean, developer will probably do " | + | |
- | + | ||
- | Furthermore quite often developers need to parse content out of strings and pass this to other methods. With strict type checking one is now forced to explicitly type cast. While its certainly doable, its also additional work that needs to be done while writing the code (" | + | |
- | + | ||
- | It also means that users of such strict typed API's will tend to simply cast and due to laziness (PHP is used for rapid development after all) might forgo validating first if the content is really what they expected. Without type checking the burden would be with the developer providing the API. Since its usually expected that an API is fairly often, it seems illogic to move this burden to the API users. More over due to this, a new kind of bug will be introduced due to over use of cast instead of hand coded parameter validation as is currently necessary. This could lead to even higher bug rates. | + | |
- | + | ||
- | As for outside sources needing validation. This is not always the case as most people do trust that the data returned from a database is in the expected format, even though for most RDBMS it will always be returned as string. Same applies to configuration files, which if defined in something else than PHP code will most likely only return strings, but who's values will usually not be validated. | + | |
- | + | ||
- | ===== Introducing weak type checking ===== | + | |
- | + | ||
- | In Ilia's recent | + | |
- | + | ||
- | However it does not cover all specific data types. Moreover " | + | |
- | + | ||
- | A weak check would examine the content of the variable in a way that would be more strict than the standard type juggling. If the weak check passes, the value would be type casted appropriately. If the weak check fails it would trigger an E_RECOVERABLE_ERROR just as in the strict case. | + | |
- | + | ||
- | Here is a short list of examples to illustrate the weak type checking | + | |
- | + | ||
- | <code php> | + | |
- | + | ||
- | // pass a weak integer type check | + | |
- | $foo = 12; | + | |
- | $foo = 12.00; | + | |
- | $foo = ' | + | |
- | $foo = " | + | |
- | + | ||
- | // pass a weak float type check | + | |
- | $foo = 12; | + | |
- | $foo = 12.00; | + | |
- | $foo = 12.34; | + | |
- | $foo = ' | + | |
- | $foo = " | + | |
- | $foo = " | + | |
- | + | ||
- | // pass a weak bool type check | + | |
- | $foo = true; | + | |
- | $foo = false; | + | |
- | $foo = 0; | + | |
- | $foo = " | + | |
- | $foo = 1; | + | |
- | $foo = " | + | |
- | + | ||
- | // pass a weak string type check (same as strict) | + | |
- | $foo = " | + | |
- | $foo = " | + | |
- | $foo = " | + | |
- | + | ||
- | // pass a weak scalar type check (same as strict) | + | |
- | $foo = true; | + | |
- | $foo = false; | + | |
- | $foo = " | + | |
- | $foo = " | + | |
- | $foo = 12.34; | + | |
- | $foo = " | + | |
- | $foo = " | + | |
- | + | ||
- | </ | + | |
- | + | ||
- | Further more weak type checking could also be useful once we have generic type casting support via some magic type cast method along the lines of __toString(). In this case the weak type checking would also allow an object to pass if it provides the relevant casting method, though it would then of course automatically cast the object to the given type. | + | |
- | + | ||
- | ===== Proposed API ===== | + | |
- | + | ||
- | <code php> | + | |
- | + | ||
- | // " | + | |
- | function add_user(+string name, +string phone_number, | + | |
- | + | ||
- | // " | + | |
- | function add_user(string name, !string phone_number, | + | |
- | + | ||
- | // " | + | |
- | function add_user(string name, string phone_number, | + | |
- | + | ||
- | // " | + | |
- | function add_user(string name, string phone_number, | + | |
- | + | ||
- | // Keep in mind that the " | + | |
- | function add_user(string! name, string! phone_number, | + | |
- | + | ||
- | // Furthermore one of the two modifiers could be the default | + | |
- | // optionally + is the default | + | |
- | function add_user(+string name, string phone_number, | + | |
- | // optionally - is the default | + | |
- | function add_user(+string name, +string phone_number, | + | |
- | + | ||
- | </ | + | |
- | ===== Changelog ===== |
rfc/typechecking.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1