On 13/07/2014 16:45, Zeev Suraski wrote:
Even reading Nikita's piece, he's saying he dislikes that option for 'obvious reasons', but I see nothing obviously wrong with this approach. [...] Unlike what's suggested in that piece, it's not equivalent at all to docblocks, as it is in fact enforced, and as you said, has the benefit of being able to write the 'inner code' without worrying about the input types.
I think you're muddling two sections of Nikita's article [1]. The option which is dismissed "for obvious reasons" is "unenforced type hinting" - keywords which do absolutely nothing other than give a literal hint to non-critical tools like documentation and reflection.
The next section is about "casting weak type hinting", which is described as "one of the more interesting proposals". It certainly has merit, although in my opinion it's less powerful than the other options in what it adds to the language, as the equivalent userland boilerplate is really minimal (e.g. $foo = (int)$foo).
As I've mentioned elsewhere, and indeed was mentioned in Anthony's proposal at the time [2], the addition of warnings on lossy casts is a completely separate issue to the ability to sugar those casts into a function signature.
Now, what is being proposed here is effectively "casting strict type hinting", a variant of what Nikita called "strict weak type hinting", with the additional step of actually applying the lossless cast, rather than just asserting that it's possible. This actually provides a lot of functionality which is fiddly to implement in userland, and I can't see a lot of uses for asserting that a cast would be non-lossy, if you're not about to perform that cast (which is what "strict weak type hinting" allows).
[1] http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html
[2] http://blog.ircmaxell.com/2012/03/parameter-type-casting-in-php.html -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
