Everything

php

Home » Project » Newsgroups » php.internals » [RFC] Enable strict_types checking for curl_setopt() »

[RFC] Enable strict_types checking for curl_setopt()

php.internals

Colin O'Dell

9 years ago

Hello internals,

I'd like to propose an enhancement to curl_setopt()
<http://php.net/manual/en/function.curl-setopt.php> which is used to
configure a given curl session.  The second argument of this function
defines which option to set and the third argument provides the
corresponding value to use.

Because each option expects the value to be a specific type, it makes sense
to enforce these types in strict type checking mode.  I'd therefore like to
propose that we introduce strict type enforcement inside curl_setopt() when
"declare(strict_types=1);" is being used.

The full details of the proposal, including the proposed patch, can be
found here: https://wiki.php.net/rfc/curl_setopt_strict_types

Huge thanks to Sara Golemon for the idea and creating the patch!

Cheers,

Colin O'Dell
colinodell@gmail.com

Sara Golemon

9 years ago

On Sat, Apr 22, 2017 at 4:40 AM, Colin O'Dell <colinodell@gmail.com> wrote:

> I'd like to propose an enhancement to curl_setopt()
> <http://php.net/manual/en/function.curl-setopt.php> which is used to
> configure a given curl session.  The second argument of this function
> defines which option to set and the third argument provides the
> corresponding value to use.
>
> Because each option expects the value to be a specific type, it makes sense
> to enforce these types in strict type checking mode.  I'd therefore like to
> propose that we introduce strict type enforcement inside curl_setopt() when
> "declare(strict_types=1);" is being used.
>
> The full details of the proposal, including the proposed patch, can be
> found here: https://wiki.php.net/rfc/curl_setopt_strict_types
>

A note on the current state of the PR: Colin's RFC is based on the
first commit in that PR, but after more thought and some feedback from
NikiC, I piled a refactor on top of it which quite notably changes the
weak-mode handling.  See
https://github.com/php/php-src/pull/2495#issuecomment-296383366

So some decisions to make yet regarding precisely *how* we'd land the
final commit, but I hope we can all agree the intent stated in the RFC
is pretty sound: Improve type checking in curl_setopt() without
screwing over the majority of existing users.

-Sara

Stas Malyshev

9 years ago

Hi!

> Because each option expects the value to be a specific type, it makes sense
> to enforce these types in strict type checking mode.  I'd therefore like to
> propose that we introduce strict type enforcement inside curl_setopt() when
> "declare(strict_types=1);" is being used.

While it may make sense to check types per-option, that's not exactly
what scalar types are supposed to do - this is not argument typing, this
is internal function business logic, and I am not sure confusing the two
is really that good an idea.

--
Stas Malyshev
smalyshev@gmail.com

Fleshgrinder

9 years ago

On 4/24/2017 10:20 PM, Stanislav Malyshev wrote:

> Hi!
>
>> Because each option expects the value to be a specific type, it makes sense
>> to enforce these types in strict type checking mode.  I'd therefore like to
>> propose that we introduce strict type enforcement inside curl_setopt() when
>> "declare(strict_types=1);" is being used.
>
> While it may make sense to check types per-option, that's not exactly
> what scalar types are supposed to do - this is not argument typing, this
> is internal function business logic, and I am not sure confusing the two
> is really that good an idea.
>

I completely agree with Stanislav at this point. `curl_setopt` can and
probably should validate the types of the various options, it may even
throw a `TypeError`, but it most certainly should not depend on the
`strict_types` declaration.

--
Richard "Fleshgrinder" Fussenegger

Sara Golemon

9 years ago

On Mon, Apr 24, 2017 at 1:24 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 4/24/2017 10:20 PM, Stanislav Malyshev wrote:
>> Hi!
>>
>>> Because each option expects the value to be a specific type, it makes sense
>>> to enforce these types in strict type checking mode.  I'd therefore like to
>>> propose that we introduce strict type enforcement inside curl_setopt() when
>>> "declare(strict_types=1);" is being used.
>>
>> While it may make sense to check types per-option, that's not exactly
>> what scalar types are supposed to do - this is not argument typing, this
>> is internal function business logic, and I am not sure confusing the two
>> is really that good an idea.
>>
>
> I completely agree with Stanislav at this point. `curl_setopt` can and
> probably should validate the types of the various options, it may even
> throw a `TypeError`, but it most certainly should not depend on the
> `strict_types` declaration.
>

I disagree. From the user's perspective it is argument typing.  The
internal implementation detail of that argument type being dependent
on another arg's value is just a detail.

-Sara

Stas Malyshev

9 years ago

Hi!

> I disagree. From the user's perspective it is argument typing.  The

Not really. Argument typing is when arguments have types. curl_setopt
arguments do not have known types, they have business logic inside that
says if argument X is equal to this, then argument Y must be of that
type. It's very different from what strict_types does.

> internal implementation detail of that argument type being dependent
> on another arg's value is just a detail.

It's not "just a detail", it's the whole point of it. The value argument
does not have a know type, it is typed only when you know the exact
value of another argument (and sometimes not even then - e.g.
CURLOPT_POSTFIELDS accepts both strings and arrays). We don't have "type
that is defined by another type" in the type system, it's clearly
business logic. Which I have no problem with, but it shouldn't be part
of type system then.

--
Stas Malyshev
smalyshev@gmail.com

Sara Golemon

9 years ago

On Mon, Apr 24, 2017 at 4:09 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

> it's clearly
> business logic. Which I have no problem with, but it shouldn't be part
> of type system then.
>

We're certainly arguing semantics at this point.  Let's agree that
type enforcement is a good thing (which you seemed to say in your
first response) and move on to how that's implemented.

Why shouldn't we allow the same call-time decision making around
strict/weak enforcement to apply to "business logic" type enforcement
as it does to argument types?  Surely consistency is a good thing as
well?

-Sara

Michał Brzuchalski

9 years ago

25.04.2017 01:56 "Sara Golemon" <pollita@php.net> napisał(a):

>
> On Mon, Apr 24, 2017 at 4:09 PM, Stanislav Malyshev <smalyshev@gmail.com>

wrote:

> > it's clearly
> > business logic. Which I have no problem with, but it shouldn't be part
> > of type system then.
> >
> We're certainly arguing semantics at this point.  Let's agree that
> type enforcement is a good thing (which you seemed to say in your
> first response) and move on to how that's implemented.

I agree with Stanislav. IMHO argument types are valueable when are
reflective by reflection and curl_setopt has no valuable info by reflection
and will never be. Curl implementation also uses resources cURL handle is
used. Maybe it's time to refactor and provide objects with option setters
with argument types?

Sara Golemon

9 years ago

On Mon, Apr 24, 2017 at 9:00 PM, Michał Brzuchalski
<michal.brzuchalski@gmail.com> wrote:

> I agree with Stanislav. IMHO argument types are valueable when are
> reflective by reflection and curl_setopt has no valuable info by reflection
> and will never be. Curl implementation also uses resources cURL handle is
> used.
>

Literally zero internal functions have argument type reflection
(beyond class and array types).  curl_setopt() is not and would not be
any different in this regard.

https://3v4l.org/2BtPW

> Maybe it's time to refactor and provide objects with option setters
> with argument types?
>

I do agree there.  I've got a WiP "cURLi" extention in my homedir that
I've been poking at since ZendCon 2016.  I suppose if we don't put
type checking in curl_setopt() then that'll just push users who care
about type safety towards cURLi. :D

-Sara

Rowan Collins

9 years ago

On 25 April 2017 16:56:57 BST, Sara Golemon <pollita@php.net> wrote:

>> Maybe it's time to refactor and provide objects with option setters
>> with argument types?
>>
>I do agree there.  I've got a WiP "cURLi" extention in my homedir that
>I've been poking at since ZendCon 2016.  I suppose if we don't put
>type checking in curl_setopt() then that'll just push users who care
>about type safety towards cURLi. :D

Oh, lordy, yes please! The curl API is absolutely horrible, and just crying out for a more sane wrapper to be built into the language, rather than everyone writing their own messy classes.

Please can we also set some sane defaults (e.g. CURLOPT_RETURNTRANSFER) and a small amount of extra logic (e.g. capturing return headers) so that using it doesn't require a dozen lines of boilerplate to be useful?

Thanks,

--
Rowan Collins
[IMSoP]

Fleshgrinder

9 years ago

On 4/25/2017 5:56 PM, Sara Golemon wrote:

> On Mon, Apr 24, 2017 at 9:00 PM, Michał Brzuchalski
> <michal.brzuchalski@gmail.com> wrote:
>> I agree with Stanislav. IMHO argument types are valueable when are
>> reflective by reflection and curl_setopt has no valuable info by reflection
>> and will never be. Curl implementation also uses resources cURL handle is
>> used.
>>
> Literally zero internal functions have argument type reflection
> (beyond class and array types).  curl_setopt() is not and would not be
> any different in this regard.
>
> https://3v4l.org/2BtPW
>
>> Maybe it's time to refactor and provide objects with option setters
>> with argument types?
>>
> I do agree there.  I've got a WiP "cURLi" extention in my homedir that
> I've been poking at since ZendCon 2016.  I suppose if we don't put
> type checking in curl_setopt() then that'll just push users who care
> about type safety towards cURLi. :D
>
> -Sara
>

Way to go. This RFC is just wrong, and not _simply_ about semantics.

--
Richard "Fleshgrinder" Fussenegger

Andrew Faulds

9 years ago

Hi Michał,

Michał Brzuchalski wrote:

>IMHO argument types are valueable when are
> reflective by reflection and curl_setopt has no valuable info by reflection
> and will never be.

Neither do the vast majority of internal functions with parameter type
checking.

--
Andrea Faulds
https://ajf.me/

Markus Fischer

9 years ago

Hi,

On 22.04.17 13:40, Colin O'Dell wrote:

> Hello internals,
>
> I'd like to propose an enhancement to curl_setopt()
> <http://php.net/manual/en/function.curl-setopt.php> which is used to
> configure a given curl session.  The second argument of this function
> defines which option to set and the third argument provides the
> corresponding value to use.
>
> Because each option expects the value to be a specific type, it makes sense
> to enforce these types in strict type checking mode.  I'd therefore like to
> propose that we introduce strict type enforcement inside curl_setopt() when
> "declare(strict_types=1);" is being used.

I'm sorry to say but I think this /approach/ is a horrible idea :(

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.

regards,
- Markus

Sara Golemon

9 years ago

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?

-Sara

Rowan Collins

9 years ago

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. 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*.

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.

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.

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.

That leaves us with either checking the types unconditionally (a significantly breaking change) or introducing a new, type-safe, API. 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.

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.

Regards,

--
Rowan Collins
[IMSoP]

Sara Golemon

9 years ago

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

Rowan Collins

9 years ago

On 28 April 2017 22:30:35 BST, Sara Golemon <pollita@php.net> wrote:

>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.

Just to clarify, I jumped into the thread to put my explanation of what I think people were objecting to. It is not my words you are quoting there, they don't speak for me, and I don't speak for them. My apologies for the confusion.

Personally, I don't think the literal fact of reflection not being available is all that relevant either way. It's certainly not the objection I was raising.

>> 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.  See pg_*() functions for
>my favorite example of this, though there are several examples in
>standard as well.

Then I stand corrected. I was unaware that there were already internal functions which performed checking that couldn't be done the same way in userland; specifically, that checked more than basic signatures, but only under strict_types mode. Nor did I spot those examples in this thread, so it's possible that other people are also unaware of that precedent. But again, to be clear, it may just be me.

>> 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.

Fair enough.

>> 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.

I never claimed to have any sort of veto, I don't even have formal voting rights, I just have an opinion. What I meant was "it leaves two options which I would back right now, based on the reservations I just explained". Other people can back whatever options they like, including the fourth option of "no change", or ideas neither us have thought of.

>> 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.

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 better API than a weird polymorphic function with a manual page a mile long.

Regards,

--
Rowan Collins
[IMSoP]

Sara Golemon

9 years ago

On Fri, Apr 28, 2017 at 6:05 PM, Rowan Collins <rowan.collins@gmail.com> wrote:

>>I reject the idea of making a worse API for the sake of an artificial
>>purity standard which has long since been violated elsewhere.
>
> 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 better API than a weird polymorphic
> function with a manual page a mile long.
>

We can agree on this, and others in this thread have said as much as
well.  I've also mentioned that I've been poking at a new curl binding
since last November.  Funnily enough, it's a mix of a
monolithic/polymorphic setOpt() method and where appropriate,
setSomeSpecificThing() methods.

When I get it to a stable point I'll toss it on github.

-Sara

Rowan Collins

9 years ago

On 29 April 2017 00:30:06 BST, Sara Golemon <pollita@php.net> wrote:

>On Fri, Apr 28, 2017 at 6:05 PM, Rowan Collins
><rowan.collins@gmail.com> wrote:
>>>I reject the idea of making a worse API for the sake of an artificial
>>>purity standard which has long since been violated elsewhere.
>>
>> 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 better API than a weird polymorphic
>> function with a manual page a mile long.
>>
>We can agree on this, and others in this thread have said as much as
>well.  I've also mentioned that I've been poking at a new curl binding
>since last November.  Funnily enough, it's a mix of a
>monolithic/polymorphic setOpt() method and where appropriate,
>setSomeSpecificThing() methods.

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".

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.

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.

Regards,

--
Rowan Collins
[IMSoP]

Sara Golemon

9 years ago

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

Fleshgrinder

9 years ago

On 4/29/2017 5:53 PM, Sara Golemon wrote:

> 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().
>

There is nothing wrong about having business rules inside that check
types based on another argument. The problem we are pointing out is
about those business rules making use strict types.

On 4/29/2017 5:53 PM, Sara Golemon wrote:

> 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
>

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.

I expect strict types to affect the arguments I pass to a routine, not
more, not less. The fact that internals are not reflective is sad, we
most probably should do something about that. Regardless, this
expectation and/or assumption holds true.

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

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.

--
Richard "Fleshgrinder" Fussenegger

Markus Fischer

9 years ago

Hi,

On 29.04.17 17:53, Sara Golemon wrote:

> 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.

I selected unfortunate words and wanted to mention reflection as an
example (in retrospect a bad and confusing one), but would I really
meant was the "user readable / visible" contract of the function
definition, as in: "you look at it and know what to expect what it accepts".

I've read through the thread and see your arguments but, to me, the fact
that this is "nested hidden" in the data structure passed to the
function still doesn't want me to have this dependent on the strict
types. I feel that strict types is misused here.

regards,
- Markus