Hi, On Fri, Jan 16, 2015 at 2:29 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > Mike Willbanks wrote on 15/01/2015 16:55: >> >> It also means that then a library developer would >> need to handle conditions on both sides (when in weak vs. strict). So I >> don't really understand where the gains of this would come from and it >> actually causes me concern in that what if a developer forgets to define >> strict and you're entire system is built on strict. > > > In case this hasn't been repeated enough times already: No They Would Not. > > As a library developer, you do not rely on strict or weak hints, you rely on > the variables you receive being of the types you require. This is guaranteed > in both modes. > > You cannot stop the user of your library doing whatever it takes to get past > your validation. It is up to them to provide sane inputs to your published > API, and no version of type hinting can change that.
This is mostly true, but relying on the variable that you receive inside a function is different from relying on the variable that gets passed to a function. Yes, there will be users who will simply do an explicit cast, but there will also be users who will take notice of the produced error, and ask themselves why first, instead of immediately trying to "override" it. Many developers want to do that, regardless of the reasons why. Some just like the strict philosophy better, some see it as a way of educating their users, and others use it sparingly. Try arguing with anybody writing crypto code and they will all tell you that any case of uncertainty must be handled with a *hard* failure. You may not agree that it is necessary, but that doesn't make it invalid. And intentionally allowing only one guaranteed behavior does imply that the other is invalid. For the Nth time - if I want to achieve that effect, I will code for both cases by not using the feature and doing is_int(), is_string(), is_bool(), etc. checks, so the language might as well help me do it. I would understand if it was not helping with something that's just wrong, but this is not the case at all here. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
