|
|
|
|
|
by ciarand
4514 days ago
|
|
I've read that article, and like most of the commentators I'd like the option for strict type hinting. It's a choice I make, it's not forced on me. Having strong type hints removes any doubt from the code. I know exactly what's being passed around and what it represents, and I can be comfortable in knowing what that means. I don't need the engine to do anything magic[1] in the background. While the idea of "strong weak type hinting" is interesting, and would certainly be useful for some code (especially libraries), it's not what I want from type hinting. At least 70% of the bugs I encounter in the wild are due to unexpected types. SWTH doesn't fix that - if I pass in a string and it looks like a number, the function will blindly accept it. That's not a behavior I want, that's something I want caught before I even think about deploying. I guess it depends on what you expect type hinting to provide you, but it looks like I'm not alone in wanting guaranteed safety (Facebook and Box seem to agree). Only strict typehinting fixes that. But, if the community decides that SWTH is worth pursuing I'd like to choose a syntax structure that allows both to coexist. "foo(int $int)" can be strongly-typed, while "foo(~int $int)" can be strongly weakly typed. [1]: http://www.php.net/manual/en/security.magicquotes.php Edit: forgot link |
|
> At least 70% of the bugs I encounter in the wild are due to unexpected types. SWTH doesn't fix that - if I pass in a string and it looks like a number, the function will blindly accept it.
I'm trying to think of an example where that wouldn't be what you want, and I can't! All the input you get from users is going to strings, most input you get from databases is going to be strings, text files are going to be strings. And since casting in PHP is so permissive, forcing strict typing is like having no typing at all.
The fact that a scalar variable has a specific binary representation is an implementation detail and PHP mostly doesn't care. The fact that a number is represented by 8 bytes two's-complement or 5 bytes ASCII really shouldn't matter. PHP plays a bit too loose with those rules but SWTH would fix a lot of that. I don't why it's necessary to force the caller to provide the correct internal representation for a value when it can be converted to the right representation without data loss or confusion. The function still gets the value it expects.
The only amendment I would add to SWTH, as I said already, is having it cast to the hinted type before the function call. With that, I can't see what argument there really is against it.