Hi! > The problem with making this RFC do the lossy thing is it then > removes one key advantage of it: that this RFC provides a measure of > strictness. Without that, we have no real compromise proposal, and we > might as well introduce a second set of “strict” type hints. The > whole point of the current behaviour is that it compromises between > the weak typing and strict typing camps; doing what zpp does is > giving in to the former camp, and then it’s not a compromise any > more, is it?
I think if the compromise is having multiple set of rules for implicit casts then this compromise is not worth it. If you answer to the question of "what happens if I use a string in boolean context" with "well, it depends, if it's boolean context in syntax construct, it's one rule, if it's internal function, another, if it's user function, yet another" - it's not a good compromise. Any solution where you can give an actual answer like "empty string is false, all others are true" is much better. I'm not a fan of strict types in PHP, but having inconsistent rules is IMO so bad that even strict types would be better. At least you'd then know on which planet you are. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
