Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98901
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.128.179 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <398456D8-170A-4629-B6FF-D64F6DDB9C9A@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>
Date: Fri, 28 Apr 2017 16:30:35 -0500
Message-ID: <CAESVnVqWHD6mf6oxO9n+WcaMCXOJWfob=ikKNGy-v4KwnGoz-A@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()
From: pollita@php.net (Sara Golemon)

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.

> The objection is that type checking currently only occurs at function boundaries:
> their signatures are matched against provided parameters, and their return
> declarations against returned values. The entire feature is equivalent to the
> compiler injecting either casts (weak mode) or assertions (strict mode) at the
> beginning and end of function definitions, *and nowhere else*.
>
But that isn't how strict type enforcement works in internal
functions.  I realize I'm being pedantic here, but since the objection
is on semantics grounds, I feel I must apply the same standards of
semantics to the counter argument.

The state of the PR at the moment is to apply function-entrance
criteria to arguments, the only thing which makes it (somewhat)
special is the degree of deferment from the C function entry till the
types are checked.  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.

> This RFC introduces a check at a different point in the function:
> after the parameters have been examined, based not on the
> signature of the function, but an internal set of rules.
>
Repeat; See above, this is not unique.

> Notably, this is not a type of check that could be made in a userland function -
> or, rather, it would have to be made unconditionally, since the strict_types setting
> is explicitly invisible to the callee.
>
Agreed, but userland and internal functions are not created equal and
this behavior is still not without precedent.

> 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.

> 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.

> 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.

> As I mentioned, I think the entire PHP curl API is unnecessarily complicated
> to use, and the overloading of parameter types in curl_setopt actually
> contributes to this rather than simplifying anything.
>
I agree that the overloading of the curl_setopt() function is the
cause of a problem.  I just disagree that allowing opt-in validation
of those types fails to solve it.

-Sara