Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98912
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 74.125.82.67 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <DFB50B80-50F5-42B4-9AB2-B620525A2B3F@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> <CAESVnVq-gF2M-She6Rpp2_PVNX+EWaHUEb3xcZt24-q96Njvyg@mail.gmail.com>
 <b979c999-0d1e-ccfa-e231-c661f18e0b5d@fleshgrinder.com> <CAESVnVoppYrPxbwxZJU-xzh-NUrse+0Qn8H4UZ3FUacKKsTBGg@mail.gmail.com>
 <DFB50B80-50F5-42B4-9AB2-B620525A2B3F@gmail.com>
Date: Sat, 29 Apr 2017 15:19:51 -0500
Message-ID: <CAESVnVquZPJvcwjehUQ6U-3sw9R7uut_DU4xxFc1XT4s5aaq6A@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 2:46 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> In this case, we should acknowledge that userland cannot
> (delta dirty backtrace hack) change behaviour based on
> strict types inside the body of the function, and in most
> cases neither sold internal functions. We can then decide
> if this use case merits breaking that rule or not.
>
That's a conversation I can agree needs to be had.  My position should
be pretty obvious wrt curl_setopt(), but I would actually state that
I'd go *further* by saying we should allow userland functions to know
if they were called strictly or not, and the reason is: Union Types.

Union Types (and intersection types and several other complex
variants) have been argued against (reasonably, I would say) on the
merit that the syntax gets ugly quite quickly and anyway, userspace
and implement the equivalent of arbitrarily complex types in the
opening body of their functions.

What such workarounds *can't* do, is know how much to freak out when
called incorrectly.  If, as an author of a function, I *want* to
respect weak mode, I don't have that option currently (barring said
backtrack hacks).

I realize this is getting off-topic by venturing into a whole separate
RFC discussion, but as you point out it's a salient one when it comes
to deciding how much intelligence curl_setopt() should apply.

Then again, I think operator overloading belongs in userspace as well,
so there's no accounting for taste.

-Sara