On May 23, 2010, at 8:51 AM, Lukas Kahwe Smith wrote: > > On 23.05.2010, at 14:44, Sebastian Bergmann wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 05/23/2010 01:08 AM, Ilia Alshanetsky wrote: >>> any mistmatch results in an error >> >> An error that is recoverable. So not only is the "strict typing" >> optional, but "type mismatches" can be caught and handled. > > again .. are you saying that a recoverable error is more than a way to > display a nice error message instead of a white screen? > > anyway, the fundamental question at hand is where the "burden" of correct > typing should be placed, on the API consumer or on the API provider. this > also ties in with the question if API consumers are likely to have "properly" > typed (aka typed in the way the _various_ API he consumes expect) by default > or not. i think this is the key question to answer when deciding to go with > enabling type hinting or full out strict typing.
We also already have a precedent for type-caring functions in the ctype_* functions: $ php -r 'var_dump(ctype_digit(123), ctype_digit((string) 123));' bool(false) bool(true) ctype_digit() simply returns a false when a non-string is passed in. Everybody knows you just cast the param to string (as in my second call); and with no help from a notice or error of any kind. I think if we type-juggle the inputs, and threw a _notice_, people who *care* about the precision of their data, will be informed by the notice and can change it. Everyone else will just get expected behavior for the function with their data. It might be useful to have some way to figure out that a variable was cast however, is that something we can store in the ZVAL and pull out with a function? (only the type casting that occurs due to this mechanism, not any other). I don't think this is useful enough for any kind of performance hit mind you ;) - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
