Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98907 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39272 invoked from network); 29 Apr 2017 16:11:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Apr 2017 16:11:46 -0000 Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.89 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.89 mx108.easyname.com Received: from [77.244.243.89] ([77.244.243.89:50522] helo=mx108.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DF/46-01540-D3BB4095 for ; Sat, 29 Apr 2017 12:11:43 -0400 Received: from cable-81-173-132-37.netcologne.de ([81.173.132.37] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1d4UyA-0000Ny-Kt; Sat, 29 Apr 2017 16:11:38 +0000 Reply-To: internals@lists.php.net References: <398456D8-170A-4629-B6FF-D64F6DDB9C9A@gmail.com> <5B258485-B7EE-4DCD-B93F-B036E9B6D4CC@gmail.com> <8F7D0233-DB1A-4617-8E92-C1719D4D385D@gmail.com> To: Sara Golemon , Rowan Collins Cc: PHP internals Message-ID: Date: Sat, 29 Apr 2017 18:11:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kRBaqgxukbUx6Bp24DnlpOwm8sOiS0hRL" X-DNSBL-PBLSPAMHAUS: YES Subject: Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt() From: php@fleshgrinder.com (Fleshgrinder) --kRBaqgxukbUx6Bp24DnlpOwm8sOiS0hRL Content-Type: multipart/mixed; boundary="WkoJcpAjSvw3GWGSmPjNlKScasaBwJWFO"; protected-headers="v1" From: Fleshgrinder Reply-To: internals@lists.php.net To: Sara Golemon , Rowan Collins Cc: PHP internals Message-ID: Subject: Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt() References: <398456D8-170A-4629-B6FF-D64F6DDB9C9A@gmail.com> <5B258485-B7EE-4DCD-B93F-B036E9B6D4CC@gmail.com> <8F7D0233-DB1A-4617-8E92-C1719D4D385D@gmail.com> In-Reply-To: --WkoJcpAjSvw3GWGSmPjNlKScasaBwJWFO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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(). >=20 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. >=20 > 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. >=20 > 2. Type enforcement should not depend on the declare(strict_types=3D1);= 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). >=20 > -Sara >=20 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. --=20 Richard "Fleshgrinder" Fussenegger --WkoJcpAjSvw3GWGSmPjNlKScasaBwJWFO-- --kRBaqgxukbUx6Bp24DnlpOwm8sOiS0hRL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZBLsuAAoJEOKkKcqFPVVrb50P+gOhBuPOdnHRmdIX6mnd3QXr LzkGpRtRn/Xkj3rUgMcrYk7FrUkqWQQ2ChaQV9XPAdF4pERQLXKFrGFxoR+vpa8b 1EWnox0SCNw+Rh9K+cE4KN27bp8ked7GT92soMSf/2EPsRGNhkvLCEUPQlWhNqP4 wrM9tBFJUQUQ8XYz5T1OVDCl5wwm34S9KPXKhWXunYApd6kBFQDZyGrLxYolgMnJ 6MrZy4PZuGTxqSkgIF5j8hLMgqOz9ivLJFUXiKcPH8nmBZMSLglm38M50CcPssCD BE36MNDhYjRvcFMT8QXL0KZfUS3D8Y5GYPq/O96F31SrdYvAs2w7y8Is9FbZwj/z on/T79upW2Ivhs4VikpBVUtv9u2h0Zdn55fe7wDmcHK4hmEChoZfNblrUZy7GcSd B4DwPRnn8tWI4OOvDzwlP55o/mWvoNh5l7THWmMoHgwLfbn8F3kaPnEC/nPpmr6d Ogi70qvjjIlZNWaJ5wQgaVCvHpst/TrK2F6ged5rTvdPwp0aihuCBTXnjtqkd0q9 /7mwDXBtEtCSNfCwbwhL3HVVQja4RvOZXni/VpKpB4nHSoBsEcrS95pdNlWOPUiN 2BYGvUdSyArkBNXFzFGsxJRWsfSkstZlHWH4VQEpLJ2DTT3fclcr9Wl0vm5YUCS7 +kx0qdoDWr9eIC7hC+h8 =pFd2 -----END PGP SIGNATURE----- --kRBaqgxukbUx6Bp24DnlpOwm8sOiS0hRL--