On 28 April 2017 18:54:09 BST, Sara Golemon <poll...@php.net> wrote: >On Fri, Apr 28, 2017 at 9:34 AM, Markus Fischer <mar...@fischer.name> >wrote: >> To me the intention of strict types is clearly on the functions >publicly >> visible contract, i.e. it's reflectable parameters and not some >business >> logic hidden inside a function. >> >So you feel that declare(strict_types=1); should never apply to >internal functions?
I don't see that assertion implied in any of the objections on this thread. The objection is that type checking currently only occurs at function boundaries: their signatures are matched against provided parameters, and their return declarations against returned values. The entire feature is equivalent to the compiler injecting either casts (weak mode) or assertions (strict mode) at the beginning and end of function definitions, *and nowhere else*. This RFC introduces a check at a different point in the function: after the parameters have been examined, based not on the signature of the function, but an internal set of rules. Notably, this is not a type of check that could be made in a userland function - or, rather, it would have to be made unconditionally, since the strict_types setting is explicitly invisible to the callee. So, while I agree that checking the argument types for curl_setopt() is highly desirable, I am sympathetic to the argument that strict_types should not alter those checks. That leaves us with either checking the types unconditionally (a significantly breaking change) or introducing a new, type-safe, API. That could mean a small but awkward set of type overloads (setBool, setInt, etc), or a large set of named setters (setReturnTransfer, setHeaders, etc) which could use normal parameter hinting to interact with strict_types. As I mentioned, I think the entire PHP curl API is unnecessarily complicated to use, and the overloading of parameter types in curl_setopt actually contributes to this rather than simplifying anything. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
