Hi!
First of all, I am talking about the typehinting syntax and mechanism here. As Derick pointed out, current typehints are strict.
Talking about "strict" vs. "non-strict" for class types is meaningless. You can consider them non-strict if you want - they convert if the conversion is available, just like the rest of PHP, with only note that conversion is *never* available. But it's just a semantic game because we are talking about different things here. Using the same syntax just confused you to think they are the same, but in PHP they are not. There are some languages where there's no primitive types or primitive types aren't different from classes - but PHP, for better or worse, as of now is not one of them.
Secondly, I don't support amalgaming userland with internal functions. If I was to treat those internal functions as if they were written in userland, I'd say that they don't use scalar typehints, specifically for the reason you mentionned. Internal functions just typecast whatever you throw at them, no question asked.
Again, it's just semantic games - you can call it "typehints" or not, your choice, but the fact is they did not fixate on the bitwise representation of the types - and we shouldn't start fixating on that now. They accept "1" when numeric value is needed, why can't you?
Again, I'm not talking about internal functions but typehinting. Now, when a userland developer uses typehints it means they expect a variable of a certain type to be passed. If they want typecasting, Derick proposes a convenient way to do that.
That's exactly what is wrong with it - developer should NOT expect "variable of certain type to be passed" (if we are talking about primitive types), because PHP is not a strictly typed language, it's a dynamic language. There could be strictly typed language with PHP syntax, no problem, but that would a) require much more than just function parameters and b) not be PHP.
The current typehinting system does not typecast. Changing that behaviour makes it ambiguous. It introduces a new behaviour grafted onto the old mechanism and without a new syntax.
It does not change any behavior - right now there's two sets of objects in PHP - primitive types and classes. Values of primitive types can be converted into another type, implicitly or explicitly, objects of classes can not.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
