Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98900
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
Date: Fri, 28 Apr 2017 20:29:52 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAESVnVogVsYTUvyOt3_nDPMNR8jeyt2vvV=RByJ1C9FP1nVOZQ@mail.gmail.com>
References: <CAJaRsPsfWtKbke8VvM-na=vCm0E6T62gmamj2V8sJiHRFB7FLQ@mail.gmail.com> <c34c89e3-41d7-afd0-e41a-34d037471603@fischer.name> <CAESVnVogVsYTUvyOt3_nDPMNR8jeyt2vvV=RByJ1C9FP1nVOZQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <398456D8-170A-4629-B6FF-D64F6DDB9C9A@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()
From: rowan.collins@gmail.com (Rowan Collins)

On 28 April 2017 18:54:09 BST, Sara Golemon <pollita@php=2Enet> wrote:
>On Fri, Apr 28, 2017 at 9:34 AM, Markus Fischer <markus@fischer=2Ename>
>wrote:
>> To me the intention of strict types is clearly on the functions
>publicly
>> visible contract, i=2Ee=2E it's reflectable parameters and not some
>business
>> logic hidden inside a function=2E
>>
>So you feel that declare(strict_types=3D1); should never apply to
>internal functions?

I don't see that assertion implied in any of the objections on this thread=
=2E The objection is that type checking currently only occurs at function b=
oundaries: their signatures are matched against provided parameters, and th=
eir return declarations against returned values=2E The entire feature is eq=
uivalent to the compiler injecting either casts (weak mode) or assertions (=
strict mode) at the beginning and end of function definitions, *and nowhere=
 else*=2E

This RFC introduces a check at a different point in the function: after th=
e parameters have been examined, based not on the signature of the function=
, but an internal set of rules=2E

Notably, this is not a type of check that could be made in a userland func=
tion - or, rather, it would have to be made unconditionally, since the stri=
ct_types setting is explicitly invisible to the callee=2E

So, while I agree that checking the argument types for curl_setopt() is hi=
ghly desirable, I am sympathetic to the argument that strict_types should n=
ot alter those checks=2E

That leaves us with either checking the types unconditionally (a significa=
ntly breaking change) or introducing a new, type-safe, API=2E That could me=
an a small but awkward set of type overloads (setBool, setInt, etc), or a l=
arge set of named setters (setReturnTransfer, setHeaders, etc) which could =
use normal parameter hinting to interact with strict_types=2E

As I mentioned, I think the entire PHP curl API is unnecessarily complicat=
ed to use, and the overloading of parameter types in curl_setopt actually c=
ontributes to this rather than simplifying anything=2E

Regards,

--=20
Rowan Collins
[IMSoP]