Yes, I understand the point of his post. But as you know - the perfect world and the real world rearly meat together. Just read the prevoius themes - majority was on the typecasting hints for the primitive types. We even layed the rules quite in detail. The thing is it will be pain in the ass to use strict typing just because the data comes in string representation from almost everywhere (PDO with mysqlnd makes a step to the right types from the database, but that's more an exception than a rule for now). I just don't think that there will be any sizeable codebase using the strict typing because one way or other the authors will just get fedup with converting data back and forth. Not to mention it just breaks the logic of the language. As Stas just wrote, people know from day one that if you feed "1" to a function expecting int, it will work just fine. In fact, the whole language and all internal functions work that way. The strict types will just break that pattern. Most of times when using some API I don't give a damn about what I get from the HTTP. I just do the blody $page = isset($_GET['page']) ? (int)$_GET['page'] : 0; to get an int. If user tries to do something by tampering with page params - he can do that as long as he want's. What that means, when strict typing is used, most of us will just do the blody conversion, because we don't wan't to get a fatal error, even if that's catchable. Converting hint will give us a warning, convert the value and off we go - log a warning, do the stuff so the user is happy. We see the error in the logs, check it, apply a fix and done with it.
It's one thing if "12blabla" makes into 12 int (sure I want to get a warning in the logs) or 1 becomes 1.0 for float (totally safe and sound). It would be good to see say 5 convert to true for bool - it's totally fine (again log an error/warning, this should be fixed). And it's totally different when we expect an array or an object of some type as a param. The handling of these structures just totally differes. To work with them you use different syntax, different aproaches. You can't substitute an array with something, same with objects. They should fit perfectly. It's not the reason to implement primitive type hinting like array and object type hints just because arrays and objects are done that way. Objects and arrays have a specific use syntax with special language constructs. If I expect an array - it should be an array or I will get a fatal error when trying to access an index for an int give, or try to access a method for the wrong object. But you can easilly expect a string and get an int instead, silently convert it to string and work as expected. Remember the main PHP principle? KISS. So keep it, blody hell, simple! Let the type hints to cast types when it's possible for primitive types! Personally I don't want to remember that there are two ways of defining a type hint and dig for bugs when others ment strict type hint, but wrote a typecasting one and forgot to make some checks before passing the argument relying on the hint. 2010/8/11 Josh Davis <php...@gmail.com>: > Derick's point was about consistency. The approach described in his > mail is consistent with current syntax and mechanism(s). Current > typehints do not apply any kind of conversion, so treating scalar > hints the same way is consistent with the current mechanism. > > Reusing the typecasting syntax for typecasting "hints" makes them more > familiar to the users, and it is less ambiguous than a typehint that > sometimes also typecasts. Plus, it allows for both "strict" > typechecking and the more relaxed typecasting thing instead of forcing > one. And all of that with a syntax that feels familiar. > > That, I believe, was his point. > > -JD > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
