| Both sides previous revisionPrevious revision | Next revisionBoth sides next revision |
| rfc:typecheckingweak [2009/07/12 13:43] – Change to Type Enforcement, add feedback from Guillaume Rossolini zeev | rfc:typecheckingweak [2009/07/12 13:52] – Some fixes and additions. zeev |
|---|
| ^ '1' (string) | //as-is// | 1.0 | 1 | 1 | true | | ^ '1' (string) | //as-is// | 1.0 | 1 | 1 | true | |
| ^ '12' (string) | //as-is// | 12.0 | 12 | 12 | true | | ^ '12' (string) | //as-is// | 12.0 | 12 | 12 | true | |
| | ^ '0xA' (string) | //as-is// | 10.0 | 10 | 10 | true | |
| ^ '12abc' (string) | //as-is// | //fail// | //fail// | //fail// | //fail// | | ^ '12abc' (string) | //as-is// | //fail// | //fail// | //fail// | //fail// | |
| ^ '12.0' (string) | //as-is// | 12.0 | 12 | 12.0 | true | | ^ '12.0' (string) | //as-is// | 12.0 | 12 | 12.0 | true | |
| ===== Comparison with Strict Typing ===== | ===== Comparison with Strict Typing ===== |
| |
| The main 'contender' to this RFC is the Strict Typing RFC. Unlike Type Enforcement, Strict Typing is based on a strict comparison of the zval.type value. As such, it introduces an entirely new semantics to PHP, especially around parameter passing. Today, the zval.type is used only by a handful of functions (is_int() et al, gettype()), and the identity operator. The former are much more rarely than their more 'lax' siblings (is_numeric()) which are typically more appropriate; While the latter is typically used for specialized cases, e.g. when dealing with a function returning an integer, and having to tell boolean false apart. It is therefore argued that extending a zval.type-based checks into parameter passing - a center-piece of the language - will inadvertently change the theme of the language, and the expected 'lax' type checking behavior expected from it today. | The main 'contender' to this RFC is the Strict Typing RFC. Unlike Type Enforcement, Strict Typing is based on a strict comparison of the zval.type value. As such, it introduces an entirely new semantics to PHP, especially around parameter passing. Today, the zval.type is used only by a handful of functions (is_int() et al, gettype()), and the identity operator. These functions are much more rarely used than their more 'lax' siblings (is_numeric()) which are typically more appropriate; While the identity operator is typically used for specialized cases, e.g. when dealing with a function returning an integer, and having to tell boolean false apart. It is therefore argued that extending a zval.type-based checks into parameter passing - a center-piece of the language - will inadvertently change the theme of the language, and the expected 'lax' type checking behavior expected from it today. |
| |
| In that context, it's important to mention that the two most common sources for data going into PHP - input data (_GET, _POST, etc.) and data coming from the database - are almost exclusively typed as strings. While some do type conversion during the input sanitizing phase - that is not always the case, especially with data coming from the database. Strict Typing is inherently incompatible with this concept, in the sense that it assumes the underlying data type (zval.type) is identical to the semantics of the value. It does not come to say that the two cannot be used together - but they are a pretty bad fit. | In that context, it's important to mention that the two most common sources for data going into PHP - input data (_GET, _POST, etc.) and data coming from the database - are almost exclusively typed as strings. While some do type conversion during the input sanitizing phase - that is not always the case, especially with data coming from the database. Strict Typing is inherently incompatible with this concept, in the sense that it assumes the underlying data type (zval.type) is identical to the semantics of the value. It does not come to say that the two cannot be used together - but they are a pretty bad fit. |