Mike, One point of clarification:
> This is true, however, the types that you are receiving back form a > multitude of data sources might be in a mixed format (databases for example > often provide representation back as a string, non-json based web services > provide mainly as a string, etc). While I know what my data looks like > and I know I am always going to get a "string" integer back I do not want > to have to type cast this each and every time. Or that I have a boolean > integer representation that is in a string... You get the point. Sure, I > could certainly go in and take 5 minutes and cast each one but I'm not > certain why the purpose is there... It specifically changes the > determination that PHP is a weakly typed language and all of a sudden I now > need to care that my string integer boolean is not actually a boolean. It's funny that you bring up boolean... With the current coercive proposal, you will still need to worry about the types: https://wiki.php.net/rfc/coercive_sth#coercion_rules Passing boolean(false) where an integer is expected will generate an error. This is a common practice, specifically around internal functions. Example: https://github.com/sebastianbergmann/phpunit/blob/a4e23a10d4eeea5fd9fe8916859a07430b94cf42/src/Util/ErrorHandler.php#L58 So yes, you'll still need to go in and cast each one **in both RFCs** (or handle the errors properly). The difference is with the dual-mode RFC you can choose not to have to cast and keep everything as-is today (or more specifically, you need to explicitly choose strict mode). And you can have user-land behave identically to internals **in both cases**. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
