Re: [RFC] Enable strict_types checking for curl_setopt()

On 28 April 2017 22:30:35 BST, Sara Golemon <pollita@php.net> wrote: >On Fri, Apr 28, 2017 at 2:29 PM, Rowan Collins ><rowan.collins@gmail.com> wrote: >> On 28 April 2017 18:54:09 BST, Sara Golemon <pollita@php.net> wrote: >>>On Fri, Apr 28, 2017 at 9:34 AM, Markus Fischer <markus@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. Just to clarify, I jumped into the thread to put my explanation of what I think people were objecting to. It is not my words you are quoting there, they don't speak for me, and I don't speak for them. My apologies for the confusion. Personally, I don't think the literal fact of reflection not being available is all that relevant either way. It's certainly not the objection I was raising. >> The objection is that type checking currently only occurs at function >boundaries: > 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. Then I stand corrected. I was unaware that there were already internal functions which performed checking that couldn't be done the same way in userland; specifically, that checked more than basic signatures, but only under strict_types mode. Nor did I spot those examples in this thread, so it's possible that other people are also unaware of that precedent. But again, to be clear, it may just be me. >> 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. Fair enough. >> 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. I never claimed to have any sort of veto, I don't even have formal voting rights, I just have an opinion. What I meant was "it leaves two options which I would back right now, based on the reservations I just explained". Other people can back whatever options they like, including the fourth option of "no change", or ideas neither us have thought of. >> 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. Personally, I think if we were designing from scratch, having a setHeaders method which took an array (and an associative one at that) would seem a better API than a weird polymorphic function with a manual page a mile long. Regards, -- Rowan Collins [IMSoP]