[wvenable]

Weak typing isn't magic, it's just weak typing. Weak typing for a web language makes a lot of sense.

> 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.

[ciarand]

>PHP plays a bit too loose with those rules

I don't think you or I disagree on this. The language does not handle strings gracefully.[1][2] The more magic casting and conversions I can remove from my codebase, the happier I'll be.

I'm sure there are some individuals that would misuse strong typing, but it would help a whole lot of people avoid some really, really dumb bugs. This isn't so much about knowing what's going on internally (binary representations), this is about being able to catch bugs early and often. It also helps in refactoring and improves the quality of linters.

But yeah, if SWTH casts if a parameter matches the definition of a type (e.g. 1.5 is not an int but 1.0 is) then SWTH is fine. There'd probably be a little bit of a performance penalty, but as long as the devs implement strict casting rules (according to Nikita's favorite proposal) then it solves my problems. As a sidenote, Nikita actually agreed to the casting change after posting that article[3].

[1]: http://phpsadness.com/sad/47 [2]: http://stackoverflow.com/a/1995196 [3]: http://www.jejik.com/articles/2012/03/a_php_type_hinting_alt...)

[wvenable]

> This isn't so much about knowing what's going on internally (binary representations)

Strong typing is all about the binary representation. SWTH just cares about the values. I don't see the advantage in caring at the call site whether or not this integer is a string of numbers or a 64bit value.

But I'd probably be as ok with strong typing as you are with Strong-weak typing if PHP's casting rules weren't so permissive. If you have a function that takes an integer but you have a string, it would be logical to cast that string to an integer. But PHP casts are very permissive, and any value can be casted from a string to an int. So casting negates the benefit of type hinting.