Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91754 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60138 invoked from network); 18 Mar 2016 20:50:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Mar 2016 20:50:18 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.122 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 212.232.28.122 mx201.easyname.com Received: from [212.232.28.122] ([212.232.28.122:41100] helo=mx201.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 34/72-42473-60A6CE65 for ; Fri, 18 Mar 2016 15:50:15 -0500 Received: from cable-81-173-135-2.netcologne.de ([81.173.135.2] 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 1ah1LV-0007I8-LU; Fri, 18 Mar 2016 20:50:09 +0000 Reply-To: internals@lists.php.net References: To: internals@lists.php.net, Marco Pivetta , Andrea Faulds , Phil Sturgeon Message-ID: <56EC69EF.1090003@fleshgrinder.com> Date: Fri, 18 Mar 2016 21:49:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8JSCSHJEgxunVjpshPs1ip7VTlaWXrX2T" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties From: php@fleshgrinder.com (Fleshgrinder) --8JSCSHJEgxunVjpshPs1ip7VTlaWXrX2T Content-Type: multipart/mixed; boundary="VqKkQ1rqWO29bUi4J7RjBGHXh23rEe0HA" From: Fleshgrinder Reply-To: internals@lists.php.net To: internals@lists.php.net, Marco Pivetta , Andrea Faulds , Phil Sturgeon Message-ID: <56EC69EF.1090003@fleshgrinder.com> Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties References: In-Reply-To: --VqKkQ1rqWO29bUi4J7RjBGHXh23rEe0HA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable First a general note on the complete nullability first: It is not up to us as language designers to decide whether it is good practice to use nullable properties or not. It is supported by many systems since ages (e.g. SQL where nullable fields are also not recommended but heck they are useful) and it is common practice in PHP. Hence, there must be support for it. That does not mean that it is endorsed in any way by us, it is just there for people who need it for the same reasons they needed it in the past 20 or so years. I also would like to repeat that ... final class A { private int $x =3D null; } =2E.. aligns perfectly with PHP 5+ syntax for optional arguments, is unambiguous (in terms of interpreting, reading, understanding, and writing), does not introduce a new syntax/keyword (e.g. /?int/) just because the cool kids from Facebook have it and -- last but not least -- developers can use /isset/ and /=3D=3D=3D null/ instead of weird checks l= ike /empty/ (super dangerous), /=3D=3D=3D -1/, /=3D=3D=3D 42/, /=3D=3D=3D 'in= valid'/, or ... you get the picture. Null is perfect for nothing and that is what null is: nothing. On 3/18/2016 12:48 PM, Marco Pivetta wrote: > To sum it up, the RFC has one major problem: it focuses on the WHEN > assignments happen, rather than just checking WHAT is assigned. >=20 > I think the scope of the proposal needs to be reduced strictly to type > checking. >=20 I know I am repeating myself but Marco summed it up perfectly and I agree to 100% with him. The checks should start with the *first userland assignment* and continue from there on to check the type *upon userland assignment*. I am stressing the /userland assignment/ because of previously mentioned functionalities of some extension like /mysqli_result::fetch_object/ or /PDOStatement::fetchObject/ who should be allowed to assign completely different types. Casting and such should be the problem of implementers. (The maintainers of the extension could of course implement auto-casting for scalar types like /int/ but more than that seems like overkill too me= =2E) On 3/17/2016 11:32 PM, Andrea Faulds wrote: > Disallowing references here might make users more aware of which > functions take parameters by reference, and avoid accidentally > modifying values. So this part of the RFC might be a good thing. > This is a noble intend, however, it makes the code harder to read and it requires silly assignment operations just to get something done. Doing stuff like ... $sort_me =3D $this->array; sort($sort_me); $this->array =3D $sort_me; =2E.. is an absolute no go, just look at it, however ... $this->array =3D array_sort($this->array); =2E.. would be awesome but the forces against clean-up and deprecations are strong in the PHP world. https://wiki.php.net/rfc/consistent_function_names We could alter the lists use (e.g.) a /ref/ keyword for stuff that requires stuff to be passed by reference and introduce new ones without i= t: - /array_sort/ ~> *new* - /array_ref_sort/ ~> /sort/ This would achieve the same goal but people could go for what they want while making them more aware. Plus, there is an upgrade path if references are to be removed from PHP at some point in the future. Well ... I think this idea is also more noble than it is really applicable, simply because there are still too many functions left that do not need a rename but a reference. :P --=20 Richard "Fleshgrinder" Fussenegger --VqKkQ1rqWO29bUi4J7RjBGHXh23rEe0HA-- --8JSCSHJEgxunVjpshPs1ip7VTlaWXrX2T 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 iQIcBAEBCAAGBQJW7GnyAAoJEOKkKcqFPVVrQLEP/iPj9+y1GmevMbWmcj84nSIt DcNkne+ULWgPvvvOd0HOOS3pt8uKEpU1/0L9IIGfdYJMB7W5Szgin/+Cr0qCEfDI OboZ2g2QnwlFslNFNL9J/4gSoee1G+qY76QFd7ocvgfggn47edrPsKx00LtHDOU3 ofo03GV/TO6D0S90aJGZQnWPLCT9NqPcFWtjD6fQPyv2PJDrPDQbHwrV+JarfhIo TQibv6Frzx+sQa7T5VVOSKasJTp1T4/1z7zHmptiSVqpui7iBHh4L35DVaQAT8Hr BmtoYG/xBubDCc4Eb2ZjBrwTc1aIGlgIz1/PkrLw4jBTyxLr04TKyUC+/5KDFpSJ 7rLHiJwH3zy2M25gzur6kqvRkJqIddVYtkpzwNbMX2lgOCYV7lQ5AAKL2uCnUnxc 3xiWprrRwGhSU59s6lW26qvWzq03cbV62UxDJ+J1hu0h0JRORhQQXYXfbdTnYiYs WvbvcgI8mJGDIemN9ResFJKLlB6MtNS6PwiyScNk4eIUZfXfX3+1njuZ0Hymbq6z A9BjT0jvqQAGHql5Y6kOdhlvgpzRFMr3SlBoTJ+OHSzAy1M0+rhxDot9qGfCurRO jtLBJeWYbWaYQwin9J740LarmKaOVOtwo2cS6ZUUblDFi5LoNuiN+YXXOZCJR8lc rBi+hJwNhqNY69MPEiM4 =AV8c -----END PGP SIGNATURE----- --8JSCSHJEgxunVjpshPs1ip7VTlaWXrX2T--