Francois, > Adding this case to 'float' meaning 'int|float' and 'callable' resolving to > 'string|array|object', are you sure it's worth the pain implementing and > supporting a dual-mode mechanism, compared to the ruleset I am intending to > propose (currently in draft): https://wiki.php.net/rfc/zpp-conversion-rules ?
I've taken a look at that proposal, and here are my comments: 1. This RFC only talks about ZPP. I assume you're also talking about exposing the same ruleset to userland? 2. You're talking about making passing `1` to a bool parameter disallowed by default. Meaning that a **LOT** of code will break automatically when upgrading to 7. Because internal function's error behavior will change. This **will** likely create a python 2/3 situation here. You're making a MASSIVE bc break here. If you were just talking about user-land types, that would be one thing. But since you're explicitly talking about ZPP, this is a bad thing. 3. It still doesn't solve the problems the strict type proponents are looking to have solved (namely that the type is what's checked, not the value). The is_numeric_string cleanup is definitely a step in the right direction (and I think should be implemented anyway), but it still doesn't solve the problem. Overall, this proposal feels like a compromise in a bad way. It makes existing code error (bc break), doesn't give the weak proponents what they want and doesn't give the strict proponents what they want either. Just because it's the middle ground doesn't make it a good thing. Please consider these issues seriously prior to making the proposal official. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
