Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98903
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.179 as permitted sender)
Date: Sat, 29 Apr 2017 00:05:34 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAESVnVqWHD6mf6oxO9n+WcaMCXOJWfob=ikKNGy-v4KwnGoz-A@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>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: Sara Golemon <pollita@php.net>
CC: PHP internals <internals@lists.php.net>
Message-ID: <5B258485-B7EE-4DCD-B93F-B036E9B6D4CC@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 22:30:35 BST, Sara Golemon <pollita@php=2Enet> wrote:
>On Fri, Apr 28, 2017 at 2:29 PM, Rowan Collins
><rowan=2Ecollins@gmail=2Ecom> wrote:
>> 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
>>
>It's implied by the statement of yours that I quoted=2E "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 logi=
c
>hidden inside a function=2E"
>
>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=2E  Your words=2E

Just to clarify, I jumped into the thread to put my explanation of what I =
think people were objecting to=2E It is not my words you are quoting there,=
 they don't speak for me, and I don't speak for them=2E My apologies for th=
e confusion=2E

Personally, I don't think the literal fact of reflection not being availab=
le is all that relevant either way=2E It's certainly not the objection I wa=
s raising=2E


>> 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=2E  See pg_*() functions for
>my favorite example of this, though there are several examples in
>standard as well=2E

Then I stand corrected=2E I was unaware that there were already internal f=
unctions which performed checking that couldn't be done the same way in use=
rland; specifically, that checked more than basic signatures, but only unde=
r strict_types mode=2E Nor did I spot those examples in this thread, so it'=
s possible that other people are also unaware of that precedent=2E But agai=
n, to be clear, it may just be me=2E


>> 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=2E
>>
>We disagree=2E

Fair enough=2E


>> That leaves us with either checking the types unconditionally (a
>significantly breaking change)
>> or introducing a new, type-safe, API=2E
>>
>It also leaves us with the third option of what is presented by the
>PR=2E  You do not have absolute veto=2E

I never claimed to have any sort of veto, I don't even have formal voting =
rights, I just have an opinion=2E What I meant was "it leaves two options w=
hich I would back right now, based on the reservations I just explained"=2E=
 Other people can back whatever options they like, including the fourth opt=
ion of "no change", or ideas neither us have thought of=2E


>> 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=2E
>>
>Eww=2E Eww=2E And eew=2E
>
>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 b=
etter API than a weird polymorphic function with a manual page a mile long=
=2E

Regards,

--=20
Rowan Collins
[IMSoP]