Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98910 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48142 invoked from network); 29 Apr 2017 17:43:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Apr 2017 17:43:24 -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.83 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.83 mx102.easyname.com Received: from [77.244.243.83] ([77.244.243.83:45026] helo=mx102.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 47/D7-01540-BB0D4095 for ; Sat, 29 Apr 2017 13:43:24 -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 1d4WOx-00037Z-2o; Sat, 29 Apr 2017 17:43:24 +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 , PHP internals Cc: Rowan Collins Message-ID: <72d76cf9-335e-314b-dbdd-491a824d31f5@fleshgrinder.com> Date: Sat, 29 Apr 2017 19:43:00 +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="d066lCQnbb0CqVJoSJIvRjVCEtlHNdjFI" X-DNSBL-PBLSPAMHAUS: YES Subject: Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt() From: php@fleshgrinder.com (Fleshgrinder) --d066lCQnbb0CqVJoSJIvRjVCEtlHNdjFI Content-Type: multipart/mixed; boundary="HtOxIbF2MqIBpctu6ShniNcCptra4pWLS"; protected-headers="v1" From: Fleshgrinder Reply-To: internals@lists.php.net To: Sara Golemon , PHP internals Cc: Rowan Collins Message-ID: <72d76cf9-335e-314b-dbdd-491a824d31f5@fleshgrinder.com> 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: --HtOxIbF2MqIBpctu6ShniNcCptra4pWLS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/29/2017 6:25 PM, Sara Golemon wrote: > 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. >=20 I only said that I do not consider GMP being a dirty hack. I still think that it is very wrong that we cannot achieve the same in userland. Operator overloading is something I would love to see. On 4/29/2017 6:25 PM, Sara Golemon wrote: > 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. >=20 No, this is about the logic inside the function and not it's signature. Part of the signature is everything before the opening brace. Of course there are still some short-comings here which I hope will be resolved in the future, e.g. union types, exceptions, generics; for those we are required to rely on documentation, for now. I for one am totally in favor of having dedicated methods for all options on an option class. It makes it straight forward to discover the possibilities that are available. The implementation is also simple with the aid of macros. Doing that would mean that the types of the arguments are part of the signature. Heck, the array arguments could be variadic and thus type safe. On 4/29/2017 6:25 PM, Sara Golemon wrote: > 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. >=20 Of course we can do it, the question is, if we should do it. It makes the language unpredictable at times, and that is a bad thing. On 4/29/2017 6:25 PM, Sara Golemon wrote: > * 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... >=20 More dirty hacks? I understand that we disagree, but do not try to tell me how I think about how things should work. Your assumptions/expectations about these things are built around the idea that strict types is a flag that changes PHP's behavior. My idea of strict types is built around the idea that it makes PHP behave they way other sane type safe languages work (the word sane limits the amount of languages to compare to, Java is definitely not part of that because of null references, but Kotlin, Ceylon, Rust, would definitely be candidates). --=20 Richard "Fleshgrinder" Fussenegger --HtOxIbF2MqIBpctu6ShniNcCptra4pWLS-- --d066lCQnbb0CqVJoSJIvRjVCEtlHNdjFI 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 iQIcBAEBCAAGBQJZBNCrAAoJEOKkKcqFPVVrTaIP/1zUGmLf1bNntDYXu7HliZ6t bXaM14cM7g0b+CMPq2h9UOAQOAeY3gPoohClnu2pQKpCDwZ1rqgwLO1zCfJTO4/c V9Ug3mCLCj7fQEzhB8kFRU1dAVw4cA8gQ6dhGE9Nueay0ZOmMVjgEaFMBiXGbUMI vPIYoadFFKT2ZWrgfUmAKrYxYCaeAKe/R7XYF3R3Rpsg7R5ZmJdY94EgGNo2FeSl uKSIACiuRnd78abWWhg/gtpDlCHWtGnjZ+sycVQJHZ6w/u8woAQC8GPIW+FalmHw jYVA5D4VJOUHILw8+fi4XF7DYQB/OvysfomsLx9L8O+0tvrne236zhusElXcGAJQ ZovSvGVPc4gaqEWhJlMMgz9ZGggM4cmIyL+hZxSGNgQ+B2ZaIbEsG6HwgQxOi6lL 6fCeeyjUgLL0VEXmXBEgvQcAk0OObvmdWFeh3e7AOhHv4ZNTvMvrpgl1OolYSp8S KZ78OlLaOqYW+kkCT9f+JitvUpadofQ5Hv5GuVJft8oKi69KbQ8pYVR0d+RZFLmt yC1ccawUaweGjidiYA3A7OqPqOXnL2RL4OymB+M5lB14YZ1ioEKe20A9uJc6i4Sc NpGyAzuD6n2hMFTvk5GTGEWj4rFtunZkOru9e3HlUoVH/jfVWMUicTJ3iZozEgPr 5Z9pXEk1mb8K/dLkto0t =LGm0 -----END PGP SIGNATURE----- --d066lCQnbb0CqVJoSJIvRjVCEtlHNdjFI--