On Fri, Apr 28, 2017 at 2:29 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > 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. > It's implied by the statement of yours that I quoted. "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."
Internal functions do not have reflectable type hints (apart from array and object), ergo by your criteria you feel that strict types does not apply. Your words. > 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*. > But that isn't how strict type enforcement works in internal functions. I realize I'm being pedantic here, but since the objection is on semantics grounds, I feel I must apply the same standards of semantics to the counter argument. The state of the PR at the moment is to apply function-entrance criteria to arguments, the only thing which makes it (somewhat) special is the degree of deferment from the C function entry till the types are checked. I say "somewhat", because it is not unique in this regard, many internal functions apply varying signatures based on initial argument and/or number of arguments. See pg_*() functions for my favorite example of this, though there are several examples in standard as well. > 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. > Repeat; See above, this is not unique. > 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. > Agreed, but userland and internal functions are not created equal and this behavior is still not without precedent. > 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. > We disagree. > That leaves us with either checking the types unconditionally (a > significantly breaking change) > or introducing a new, type-safe, API. > It also leaves us with the third option of what is presented by the PR. You do not have absolute veto. > 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. > Eww. Eww. And eew. I reject the idea of making a worse API for the sake of an artificial purity standard which has long since been violated elsewhere. > 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. > I agree that the overloading of the curl_setopt() function is the cause of a problem. I just disagree that allowing opt-in validation of those types fails to solve it. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
