Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93532 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46116 invoked from network); 25 May 2016 21:04:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 May 2016 21:04:19 -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.88 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.88 mx107.easyname.com Received: from [77.244.243.88] ([77.244.243.88:47355] helo=mx203.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6F/CC-14311-15316475 for ; Wed, 25 May 2016 17:04:18 -0400 Received: from cable-81-173-133-15.netcologne.de ([81.173.133.15] 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 1b5fyG-0005R4-Hx; Wed, 25 May 2016 21:04:04 +0000 Reply-To: internals@lists.php.net References: <7B.12.14311.F79C5475@pb1.pair.com> To: Andrea Faulds , internals@lists.php.net Cc: Marco Pivetta , Benoit Schildknecht , Niklas Keller , Stanislav Malyshev Message-ID: <1b12b09f-f190-dca0-51d9-468e9c571268@fleshgrinder.com> Date: Wed, 25 May 2016 23:03:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <7B.12.14311.F79C5475@pb1.pair.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VTh63l2XVDiooXRmxWUbSnjiccI5ionOV" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties From: php@fleshgrinder.com (Fleshgrinder) --VTh63l2XVDiooXRmxWUbSnjiccI5ionOV Content-Type: multipart/mixed; boundary="NKrh7JToBsMV9u0TeLlUegGGlvsquu1F0" From: Fleshgrinder Reply-To: internals@lists.php.net To: Andrea Faulds , internals@lists.php.net Cc: Marco Pivetta , Benoit Schildknecht , Niklas Keller , Stanislav Malyshev Message-ID: <1b12b09f-f190-dca0-51d9-468e9c571268@fleshgrinder.com> Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties References: <7B.12.14311.F79C5475@pb1.pair.com> In-Reply-To: <7B.12.14311.F79C5475@pb1.pair.com> --NKrh7JToBsMV9u0TeLlUegGGlvsquu1F0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/25/2016 5:49 PM, Andrea Faulds wrote: > PHP's existing untyped properties are implicitly initialised to null, > and so yes, we would essentially only be copying our existing behaviour= =2E >=20 > However, I think it is worth asking whether our existing behaviour is > useful before we preserve it here. From my perspective, it is unhelpful= > that PHP does not warn you about using properties you haven't > initialised, and this applies to both typed and untyped properties. In > some cases (like in my linked list example in a previous email), null > might be a meaningful value and worth distinguishing from a property no= t > having being initialised yet. >=20 > We can't change the behaviour of our existing untyped properties (or at= > least, that's beyond the scope of this RFC), but we could choose the > behaviour we find more useful for our typed properties. >=20 We already have the differentiation between IS_NULL and IS_UNDEF, why not expose the latter to userland? I mean, JavaScript has it too and people are able to understand it. class A { public int $x; public ?int $y =3D null; public int $z =3D 42; } $a =3D new A; var_dump($a->x); // undefined var_dump($a->y); // null var_dump($a->z); // 42 unset($a->z); var_dump($a->z); // undefined + error At least to me this makes sense and there would be no problem with unset() anymore. Although I truly question the usefulness of its functionality. Can anyone come up with a real world use case for unset()?= Or maybe not use /undefined/ but /unset/ as a term because it is already baked in? (Well the constant IS_UNDEF should be renamed to IS_UNSET to stay consistent in all layers.) class A { public int $x; public ?int $y =3D null; public int $z =3D 42; } $a =3D new A; var_dump($a->x); // unset var_dump($a->y); // null var_dump($a->z); // 42 // NOT SURE IF THIS SHOULD BE POSSIBLE!!!! $a->z =3D (unset) $a->z; // was null (PHP<7.1) would become unset var_dump($a->z); // unset + error $a->z =3D unset; var_dump($a->z); // unset + error unset($a->z); var_dump($a->z); // unset + error Of course this would also requires the introduction of an unset (and UNSET) constant in userland. class A { private $x; public function getX() { if ($x =3D=3D=3D unset) { $this->x =3D 42; } return $this->x; } } I love the difference to null, this makes the code much more expressive. There would be the following rules: - Access always results in error. - Usage as argument results in error. - Usage as return results in error (could be void but BC). - ... more errors ... - Comparison is possible! - The following existing operations would need to be changed to make use of unset instead of null (possible BC): - unset() - (unset) cast - The following new operations would need to be introduced: - is_unset() - The following existing operations would need to be extended: - gettype() - settype() --=20 Richard "Fleshgrinder" Fussenegger --NKrh7JToBsMV9u0TeLlUegGGlvsquu1F0-- --VTh63l2XVDiooXRmxWUbSnjiccI5ionOV 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 iQIcBAEBCAAGBQJXRhM+AAoJEOKkKcqFPVVrr4sQAJbcAugNO62OnQchBXm2LMDd fK1WvbuubbcVf2dPm7mwYPzIixVFtc+WlAPCbsXH2UjQiBKF0fai6SARtPEZrSgS J/CaL/l/LKg9VfqC8B4MgQpXMVh8k+pAuqpJL80r1uu30aIzVciytQVpo+IWoZtf RJorPXjuVXE/MVygnkroZd/PZjyf7EWv5hKaZ+Edr+w71NPy+GNpAtfvF2f2fh0F 6vIMIYdflKV73R6LCf/wVDHv1ZEy7nTOjPl7WBJdsv15JqUkdc4DSbzvCeA79cAR MuWj9zREXawsAg8MDKEPGYHdaCWWPPBQJ1EZQPGYmu+1hHESXcEmMd6EgGUsobHE gEoV0EQ5SUChj+Gnk8ZCNuoPUcSknrV1q+FeNOL0kqaOx47WNPEgrmd5A12lLDZd k3pauCRtrfFlCZdxANeTz/bErVVZrmaX5Kqn1fSGLhV+jjU5AiBmNRgdaZraNSRA YXsLkJjB3wMU+W2TRuPz7oZetUiJNKwOAqZSHKAIMemCzR+rQgJD1JsnsTqWypF1 0zoMZMslaucKOW+wTPbdOn8X5OX9ltOIM/VQfYJdqhz3tIZKzTLY3JGaWpK2b+uf jgOztNsrmnHDXyaMuYRafIQ+vlQEDgFWn6zBlRNXRY2I+qoQr59eqtVcbnH45CH6 Vgdi9j5rx5Sg1R34w+E4 =RTQr -----END PGP SIGNATURE----- --VTh63l2XVDiooXRmxWUbSnjiccI5ionOV--