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

On 29 April 2017 00:30:06 BST, Sara Golemon <pollita@php.net> wrote: >On Fri, Apr 28, 2017 at 6:05 PM, Rowan Collins ><rowan.collins@gmail.com> wrote: >>>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. >> >We can agree on this, and others in this thread have said as much as >well. I've also mentioned that I've been poking at a new curl binding >since last November. Funnily enough, it's a mix of a >monolithic/polymorphic setOpt() method and where appropriate, >setSomeSpecificThing() methods. That mix sounds very reasonable. Does it still make you go "eww" to suggest that those settings that don't deserve their own method, and take a boolean argument rather than a string or int, could have a different method, such as setFlag? Because that's really all I was suggesting: a more visible distinction that said "this method always takes a boolean", rather than "this method must be given a boolean if given this, that, or the other". Meanwhile, I'll repeat that if there really is precedent for functions validating their arguments based on both strict_types mode and the value of some other parameter, then my concern (mostly) evaporates, and I suspect others' might also. I just checked through the thread and RFC, and can't see these examples being named, so I would very much appreciate a specific example. Perhaps the precedents seem obvious to you, and that's why this whole conversation is frustrating you? It definitely feels like there is some miscommunication, because you seem surprised that people have any concerns at all. Regards, -- Rowan Collins [IMSoP]