On 11 August 2010 02:50, Stas Malyshev <smalys...@sugarcrm.com> wrote: > 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.
By "strict" typehints I meant that no typecasting occurs. Personally I'm not fan of the "strict" vs "weak" denomination used here either. I'd rather call them typechecking vs smartcasting. > 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. I'm sorry but I have no idea what you're talking about there =\ PHP has a bunch of different types, the current type hinting (typechecking as per aforementionned denomination) ensures that the argument is the right type and I hope that adding scalar type hints will not change that. > 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? I very much can, it's just not my intention. I want to be able to use type hinting/type checking as a sanity check. If I write a method whose signature is foo(int $n) I signal my intention to only accept integers. If a boolean somehow finds its way to that method, it means that something wrong happened. If I wanted to accept any type of variable then I wouldn't use a type hint and I would validate the input with the filter extension. Or I would use type casting. TL;DR version: "int $n" in the definition means I want an integer. If I wanted any kind of variable but I wanted it to somehow represent a number then I would look for a hint such as "number $n". I guess that "(int) $n" is close enough, since that's what's being used everywhere else. > 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. If PHP was meant to prevent programmers from controlling the type of their variables then I'm afraid there's been a misunderstanding and I'd say that extending a feature called "type hinting" to cover all of PHP's primitive types will only make it worse. I have always thought that controlling the type of the variables used in userland was my prerogative, and I suspect that quite a few users were led to believe the same thing. Derick's proposal allows for those users to control the type of their variables and allows for those who care about the content of their variables more than their type to do that as well. > 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. As a PHP user, I have no such notion I'm afraid. From my point of view, there's not two sets of objects, there's about ~8 types, PHP's core functions and operators do not care too much about those types and convert them internally. That's all the users see. I'm not sure what you meant by "objects of classes can not [be converted into another type]". Arrays can be cast as booleans (false is empty, true otherwise), objects can be cast as arrays (properties become keys) and strings to objects (with a single property called "scalar", leaving everybody wondering what's going on there.) TL;DR: I always thought PHP would help me control the type of my variables instead of forcing my userland code to mirror PHP's internal functions. PS: I think I've just figured out what you meant by "conversion". Were you talking about the internal conversion rules used by PHP's internal functions? Are those described somewhere in the manual? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
