Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98908
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.171 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <b979c999-0d1e-ccfa-e231-c661f18e0b5d@fleshgrinder.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> <CAESVnVq-gF2M-She6Rpp2_PVNX+EWaHUEb3xcZt24-q96Njvyg@mail.gmail.com>
 <b979c999-0d1e-ccfa-e231-c661f18e0b5d@fleshgrinder.com>
Date: Sat, 29 Apr 2017 11:25:45 -0500
Message-ID: <CAESVnVoppYrPxbwxZJU-xzh-NUrse+0Qn8H4UZ3FUacKKsTBGg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: Rowan Collins <rowan.collins@gmail.com>
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 11:11 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
> Let me be Bob, and my assumption would be completely different. I expect
> that internals behave the same as userland implementations. I know that
> this is not the case in every circumstance, but those where this
> assumption does not hold true are meant to cover very special edge
> cases, like GMP. I consider many others as being ugly hacks.
>
Your example of GMP can't be simply dismissed as "a special edge
case", it's precisely true that internals does not always follow the
same rules as userspace and often it breaks those rules for very good
reason.

> I expect strict types to affect the arguments I pass to a routine, not
> more, not less.
>
Agreed.  And that's what this proposal suggests.  If I took at your
word here, I would expect you to support this RFC.

> In other words, I consult the docs and if the signature states an
> expected type for a parameter of a routine, I expect strict types to
> validate that for me, not more, not less. The docs of `curl_setopt`
> states `mixed` for `$value` and that is what I expect.
>
> https://php.net/curl-setopt
>
Again, you're weakening your own position.  The PHP manual page for
curl_setopt() GOES ON to state the per-option types which should be
passed for $value.  I expect strict types to validate that for me, not
more, not less.  The fact that you fail to read past the first line of
the manual page doesn't invalidate the function's *total* signature.

> This does not mean that it is not allowed to throw an exception if the
> value is of another type, but it must not use strict types to determine
> its mode. Simply because I cannot do the same in userland.
>
Again, false.  The fact* that something can not be done in userland
does not preclude doing it in internals.  You mentioned one such case
at the start of your reply and there are plenty others.

-Sara

* Pedantically: This is not even true.  Using backtraces and some
simple hacks, it's quite possible to determine the caller's
strict_types setting from userspace.  But that's going off on a
tangent...