Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98905
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.181 as permitted sender)
Date: Sat, 29 Apr 2017 16:01:50 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAESVnVpHG-V_ggzyJw7k+-3gYHwnogcFKDfkuXuefmdjKm3Cmw@mail.gmail.com>
References: <CAJaRsPsfWtKbke8VvM-na=vCm0E6T62gmamj2V8sJiHRFB7FLQ@mail.gmail.com> <c34c89e3-41d7-afd0-e41a-34d037471603@fischer.name> <CAESVnVogVsYTUvyOt3_nDPMNR8jeyt2vvV=RByJ1C9FP1nVOZQ@mail.gmail.com> <398456D8-170A-4629-B6FF-D64F6DDB9C9A@gmail.com> <CAESVnVqWHD6mf6oxO9n+WcaMCXOJWfob=ikKNGy-v4KwnGoz-A@mail.gmail.com> <5B258485-B7EE-4DCD-B93F-B036E9B6D4CC@gmail.com> <CAESVnVpHG-V_ggzyJw7k+-3gYHwnogcFKDfkuXuefmdjKm3Cmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----LP9MIHVC5S18694311GRR7IHB7U2O8"
Content-Transfer-Encoding: 7bit
To: Sara Golemon <pollita@php.net>
CC: PHP internals <internals@lists.php.net>
Message-ID: <8F7D0233-DB1A-4617-8E92-C1719D4D385D@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()
From: rowan.collins@gmail.com (Rowan Collins)

------LP9MIHVC5S18694311GRR7IHB7U2O8
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 29 April 2017 00:30:06 BST, Sara Golemon <pollita@php=2Enet> wrote:
>On Fri, Apr 28, 2017 at 6:05 PM, Rowan Collins
><rowan=2Ecollins@gmail=2Ecom> 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=2E
>>
>> 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=2E
>>
>We can agree on this, and others in this thread have said as much as
>well=2E  I've also mentioned that I've been poking at a new curl binding
>since last November=2E  Funnily enough, it's a mix of a
>monolithic/polymorphic setOpt() method and where appropriate,
>setSomeSpecificThing() methods=2E

That mix sounds very reasonable=2E Does it still make you go "eww" to sugg=
est that those settings that don't deserve their own method, and take a boo=
lean argument rather than a string or int, could have a different method, s=
uch as setFlag? Because that's really all I was suggesting: a more visible =
distinction that said "this method always takes a boolean", rather than "th=
is method must be given a boolean if given this, that, or the other"=2E


Meanwhile, I'll repeat that if there really is precedent for functions val=
idating their arguments based on both strict_types mode and the value of so=
me other parameter, then my concern (mostly) evaporates, and I suspect othe=
rs' might also=2E I just checked through the thread and RFC, and can't see =
these examples being named, so I would very much appreciate a specific exam=
ple=2E

Perhaps the precedents seem obvious to you, and that's why this whole conv=
ersation is frustrating you? It definitely feels like there is some miscomm=
unication, because you seem surprised that people have any concerns at all=
=2E

Regards,
--=20
Rowan Collins
[IMSoP]
------LP9MIHVC5S18694311GRR7IHB7U2O8--