Hi! > The point of this RFC is to strike a compromise that is generally > useful rather than helping one specific use case (strict hints) or > another (casts).
What you call "compromise" is the inconsistency - it's not strict typing, it's not weak typing, it's half that and half this without any apparent principle uniting them but arbitrarily constructed table, to which anybody using it would have to constantly refer to figure out why their code is breaking. I'm sure you carefully thought about each and every cell in that table, but that does not make it any better for the user - in fact, it makes it worse, since absent the obvious uniting principle it means each time the user encounters it it has to reconstruct the long and laborious thought process anew or just learn the whole table by hard. It is not a good design. Good design is where you can predict what the language would do without remembering a bunch of exceptions that are just so. Even worse, it does not match what other functions are doing and what other type conversions are doing. It's like a "compromise" of cutting the baby in half - much worse than any of the original proposals. Only in the case of Solomon it was a trick, you on the other side propose it as a serious and preferable solution. This kind of "compromise" is not a positive thing, but a negative. -- 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
