Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92200 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21053 invoked from network); 11 Apr 2016 16:51:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Apr 2016 16:51:20 -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.25.166 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 212.232.25.166 mx210.easyname.com Received: from [212.232.25.166] ([212.232.25.166:37499] helo=mx201.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3C/72-07428-506DB075 for ; Mon, 11 Apr 2016 12:51:18 -0400 Received: from cable-81-173-133-226.netcologne.de ([81.173.133.226] 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 1apf3Q-00006x-MA for internals@lists.php.net; Mon, 11 Apr 2016 16:51:12 +0000 Reply-To: internals@lists.php.net References: <5708B197.9020108@php.net> <9C0BBB93-8173-45CF-9636-888B340828FD@ez.no> <57090928.3040905@php.net> To: php-internals Message-ID: <570BD5E6.2000304@fleshgrinder.com> Date: Mon, 11 Apr 2016 18:50:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jAhAgqu4CTUftn2ig1tQqjvksgmSpHa2n" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] Final properties From: php@fleshgrinder.com (Fleshgrinder) --jAhAgqu4CTUftn2ig1tQqjvksgmSpHa2n Content-Type: multipart/mixed; boundary="5E4Edwa3N594Tfvof5Fkkx5KG8m9E9D8i" From: Fleshgrinder Reply-To: internals@lists.php.net To: php-internals Message-ID: <570BD5E6.2000304@fleshgrinder.com> Subject: Re: [PHP-DEV] Final properties References: <5708B197.9020108@php.net> <9C0BBB93-8173-45CF-9636-888B340828FD@ez.no> <57090928.3040905@php.net> In-Reply-To: --5E4Edwa3N594Tfvof5Fkkx5KG8m9E9D8i Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable /Sending this again because the PHP mail server was down./ I thought some more about it and I think that the best choices would be *val* (for /value/) and *var* (for /variable/) as in Scala. Why? The *var* keyword is not going to be deprecated and its meaning is currently kind of ambiguous. I tried to assign it a new meaning in the thread about /Access and Visibility Modifiers/ thread (http://marc.info/?l=3Dphp-internals&m=3D146005798902985&w=3D2) but as Ro= wan Collins pointed out, it would be kind of weird to continue using *var* for anything related to access/visibility because it simply means something else; it means /variable/. The introduction of a counterpart to it would allow it to finally have a meaningful functionality and it would not introduce any kind of BC for old code. class Foo { val $x; var $y; val $z; } class Bar extends Foo { var $x; $y; $z; } The parent defines its property as being a *val* (immutable) and the extending class lifts this constraint by redeclaring it as a *var* (mutable). Doing so ensures that the developer must know what she is doing and hence makes the language overall more secure. There is no BC for the /y/ property because the parent is already mutable and implicit public (or hopefully /assembly visible/ in the future, see other references thread), hence, the /y/ in the child class simply stays mutable. The /z/ will stay a *val* (immutable) because its parent declaration is defined as such. class Point { final public float val $x =3D 0.0; final public float val $y =3D 0.0; } final class Point3d extends Point { final public float val $z =3D 0.0; } final class MutablePoint extends Point { final public float var $x; // FATAL ERROR final public float var $y; // FATAL ERROR } The *final* keyword could be added via another RFC and it would have the same meaning as the *final* keyword for classes and methods: freeze the definition. This is why the *MutablePoint* results in fatal errors: it tries to redeclare /x/ and /y/ from *val* to *var* although they are *final*. Note that this could be easily extended to local variables at a later stage as well and it would be extremely useful. I think that Scala's *val*/*var* approach could really help us to make *var* usable again in a meaningful manner and it corresponds nicely to the concept of /value objects/ and related concepts with its naming schem= e. What do you think? --=20 Richard "Fleshgrinder" Fussenegger --5E4Edwa3N594Tfvof5Fkkx5KG8m9E9D8i-- --jAhAgqu4CTUftn2ig1tQqjvksgmSpHa2n 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 iQIcBAEBCAAGBQJXC9X6AAoJEOKkKcqFPVVrx6EP/iqXGmGYPq5/GeUILOByiXe+ tCd1PPhADe8R/YZnEfi0XVxEysBePudgFCTU2YXcCPmzf5lCv8dHLxCHMj3OMxZ5 1hx4TbA+FagSs9MrRGvwtcvIaxWkbeiWB++iTqFOrTycZ1GbYSVPnSiPBYAfU92N ygJZ5nYFjqV5zV5cfxnHIgG0UNfUaQY0x1zV9XfmBGffTryQAx7dHD4Paqy1NCjX xKHrDzWDtDkILjUuqrQIrmUD+JrOZMqTglZq/DMEkueKxYULiVhTsgNd+xkpm0dh JVc6z2SgVg8M6x0TSaWkr7Ax7Ih7Aip8ceszhiS7G8sZWzX0MqmT9oGh+QvqXTxS z+a4+INHf69MF6GqUaBai2Ai2OB43wKk5TJL4dFnfIJbPvqJkKXGydW9mfDVWfEH NU1eRLRCSqcb1bgRpDWHYfv77HAueQccNdsqa5oCba+EyG4jmzR9p84q5lLLTsoL cT5FtVpq9IgWiyH/mqGNpzySuj9bdJaxpsBSBAGy5OHhhkKSqyHeafbNzyY+KRFs LBnheI8ZWzCAW27vXGWcdbKKKPRIQ1H7OdJPqw5FmU/7C6Tz2nJwQ5gcW1HnDUQA e533maxynphBQbnmQv8ezZGPCg9UE6HldgWULQUMEhFmEXR/fv2nDzxZk+IuJhCY dwdFT/JQeeJolfXRVtvR =Mqi4 -----END PGP SIGNATURE----- --jAhAgqu4CTUftn2ig1tQqjvksgmSpHa2n--