Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98906
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.176 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <8F7D0233-DB1A-4617-8E92-C1719D4D385D@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>
 <8F7D0233-DB1A-4617-8E92-C1719D4D385D@gmail.com>
Date: Sat, 29 Apr 2017 10:53:43 -0500
Message-ID: <CAESVnVq-gF2M-She6Rpp2_PVNX+EWaHUEb3xcZt24-q96Njvyg@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 Sat, Apr 29, 2017 at 10:01 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
> 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".
>
It certainly seems unnecessary.  setBool(), setInt(), setOffset(),
setString(), versus setOption() is imposing a design detail on the
consumer that shouldn't be relevant to them.  In fact, in weak mode,
it becomes especially irrelevant to know the difference between an int
and a bool setting.  Specifying type in the method name is essentially
imposing a cognitive form of strict mode on those who don't want it.

> 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.
>
Not on *both* strict mode and the value of another parameter, there's
very little application of strict mode throughout the codebase because
strict mode is new.  What there are precedents of, and what I was
responding to in your earlier email, was the idea that an arguments
type can vary based on the type and/or number of other arguments.
This precedent exists in the pg_*() methods as I already pointed you
at, and a quick grep shows stream_context_set_option(), and a
particularly fascinating "signature" in intlcal_set().

> 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.
>
I'm not surprised that there are concerns, I'm just shocked that the
concerns are so poorly founded.  Arguments I've heard so far fall into
two categories.

1. If the parameter isn't reflectable, then it shouldn't be subject to
enforcement.
This argument holds no water because internal functions can only
reflect array or object type hints, yet we enforce other types
routinely.

2. Type enforcement should not depend on the declare(strict_types=1); directive.
This argument is ridiculous on the face of it, since that's precisely
what that declare() directive was designed for.  The fact that the
type being enforced is dependent on another arg's value is an
irrelevant implementation detail.  Think about the user's experience
here.  Bob wants to call curl_setopt($ch, CURLOPT_RETURNTRANSFER,
$value);   Bob expects $value to be validated and used as a boolean.
If Bob has strict_types set, he expects an exception if $value isn't a
bool, if it's not set, he expects the value to be quietly converted
(if possible within type affinity).

-Sara