On Jul 16, 2014, at 7:03 AM, Andrea Faulds <a...@ajf.me> wrote: > On 16 Jul 2014, at 13:28, Zeev Suraski <z...@zend.com> wrote: > >> It's more of a lossy cast, exactly as we have today, that has an >> (effectively-optional-since-it's-off-by-default) to warn you about loss of >> data. >> For the vast majority of users who use the defaults, there'll be nothing new >> to learn except for the availability of those implicit casts in function >> signatures. >> For those who want to take advantage of 'loss protection', they'd have to >> learn about this extra warning type and clean their code so that it adheres >> to it. But there too, they'd have consistency, just one set of rules for >> implicit cast of scalar values across all of PHP. > > The problem with making this RFC do the lossy thing is it then removes one > key advantage of it: that this RFC provides a measure of strictness. Without > that, we have no real compromise proposal, and we might as well introduce a > second set of “strict” type hints. The whole point of the current behaviour > is that it compromises between the weak typing and strict typing camps; doing > what zpp does is giving in to the former camp, and then it’s not a compromise > any more, is it?
This is exactly why I really like this proposal. While I love the idea of super strict type annotations, I totally understand why they shouldn't be added to PHP. The RFC as it stands strikes a great balance between keeping with "the PHP way" of weak typing, while still making scalar type annotations useful. If I'm writing an app and an API I'm using has been annotated to take an "int" parameter, and I pass something that cannot possibly be an int, I want to know that, I want to know it *now*, and I don't want the program to keep executing (possibly writing bad data to a database or doing any number of other crazy things that could happen when my not-an-int gets converted to an int). The entire utility of the type annotation there is that the API developer has said "I expect an int here, if you don't pass one, you're not using the API correctly". As others have argued, the API could technically implement the "lossless conversion" logic itself, but it's fiddly at best to get right, and very error-prone. In the other direction, if the API really does want a cast-to-int-no-matter-what, it can just omit the type annotation and do that -- it's easy and not at all error-prone. I understand the argument about consistency, but I think this can be mitigated if you couch the feature correctly when documenting it, announcing it, etc, so that people get the right mental model in their heads when they first hear about it. I wouldn't talk about the type annotations this RFC proposes in terms of casts, since they aren't really quite casts (as the folks making the consistency argument have stated). They're something else -- they're type annotations (or type hints, or whatever you want to call them). In that vein, they are *consistent* with the existing strict enforcement of object type annotations, with the added detail that "strict enforcement" for scalars is defined in terms of "lossless conversion" as outlined in the RFC, since that's the "PHP way" of loosely dealing with scalar types. The idea of "lossless conversion" has just never been relevant before since there is no such thing as a lossless conversion to any object type, or from any type to an array -- but it's a completely consistent way of extending the way we deal with the existing annotations. (And not inconsistent with casts since it isn't a cast!) Josh Watzman -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
