On 4/29/2017 5:53 PM, Sara Golemon wrote: > Not on *both* strict mode and the value of another parameter, there's > very little application of strict mode throughout the codebase because > strict mode is new. What there are precedents of, and what I was > responding to in your earlier email, was the idea that an arguments > type can vary based on the type and/or number of other arguments. > This precedent exists in the pg_*() methods as I already pointed you > at, and a quick grep shows stream_context_set_option(), and a > particularly fascinating "signature" in intlcal_set(). >
There is nothing wrong about having business rules inside that check types based on another argument. The problem we are pointing out is about those business rules making use strict types. On 4/29/2017 5:53 PM, Sara Golemon wrote: > I'm not surprised that there are concerns, I'm just shocked that the > concerns are so poorly founded. Arguments I've heard so far fall into > two categories. > > 1. If the parameter isn't reflectable, then it shouldn't be subject to > enforcement. > This argument holds no water because internal functions can only > reflect array or object type hints, yet we enforce other types > routinely. > > 2. Type enforcement should not depend on the declare(strict_types=1); > directive. > This argument is ridiculous on the face of it, since that's precisely > what that declare() directive was designed for. The fact that the > type being enforced is dependent on another arg's value is an > irrelevant implementation detail. Think about the user's experience > here. Bob wants to call curl_setopt($ch, CURLOPT_RETURNTRANSFER, > $value); Bob expects $value to be validated and used as a boolean. > If Bob has strict_types set, he expects an exception if $value isn't a > bool, if it's not set, he expects the value to be quietly converted > (if possible within type affinity). > > -Sara > Let me be Bob, and my assumption would be completely different. I expect that internals behave the same as userland implementations. I know that this is not the case in every circumstance, but those where this assumption does not hold true are meant to cover very special edge cases, like GMP. I consider many others as being ugly hacks. I expect strict types to affect the arguments I pass to a routine, not more, not less. The fact that internals are not reflective is sad, we most probably should do something about that. Regardless, this expectation and/or assumption holds true. In other words, I consult the docs and if the signature states an expected type for a parameter of a routine, I expect strict types to validate that for me, not more, not less. The docs of `curl_setopt` states `mixed` for `$value` and that is what I expect. https://php.net/curl-setopt This does not mean that it is not allowed to throw an exception if the value is of another type, but it must not use strict types to determine its mode. Simply because I cannot do the same in userland. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
