Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95763 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22145 invoked from network); 7 Sep 2016 18:11:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Sep 2016 18:11:35 -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:50176] helo=mx203.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E9/B3-06456-55850D75 for ; Wed, 07 Sep 2016 14:11:34 -0400 Received: from cable-81-173-132-21.netcologne.de ([81.173.132.21] 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 1bhhJp-0001U0-QO; Wed, 07 Sep 2016 18:11:30 +0000 Reply-To: internals@lists.php.net References: <0e71d28e-1d64-5372-b58d-e54c7afae3b8@fleshgrinder.com> <642a6e78-90ea-cbf0-ec1c-376c24e568c5@fleshgrinder.com> <0800a5ca-3d14-c541-1a1a-2574ec802b8c@fleshgrinder.com> <83fa661e-2d3d-6548-a506-fb969be31c0e@garfieldtech.com> To: =?UTF-8?Q?Micha=c5=82_Brzuchalski?= , PHP Internals List , php-lists@koalephant.com, =?UTF-8?Q?Silvio_Mariji=c4=87?= , mathieu@rochette.cc, Nikita Popov , Andrea Faulds Message-ID: <56acc1d9-f424-a460-59be-3a9a1a74b198@fleshgrinder.com> Date: Wed, 7 Sep 2016 20:11:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U15qowMBUrfWgXNbmPNgRVWoS7T8w99fT" Subject: Re: [PHP-DEV] RFC - Immutable classes From: php@fleshgrinder.com (Fleshgrinder) --U15qowMBUrfWgXNbmPNgRVWoS7T8w99fT Content-Type: multipart/mixed; boundary="uSSDkoAHDW3XDg9PP4RVwxMo1gT1Q2DmV"; protected-headers="v1" From: Fleshgrinder Reply-To: internals@lists.php.net To: =?UTF-8?Q?Micha=c5=82_Brzuchalski?= , PHP Internals List , php-lists@koalephant.com, =?UTF-8?Q?Silvio_Mariji=c4=87?= , mathieu@rochette.cc, Nikita Popov , Andrea Faulds Message-ID: <56acc1d9-f424-a460-59be-3a9a1a74b198@fleshgrinder.com> Subject: Re: [PHP-DEV] RFC - Immutable classes References: <0e71d28e-1d64-5372-b58d-e54c7afae3b8@fleshgrinder.com> <642a6e78-90ea-cbf0-ec1c-376c24e568c5@fleshgrinder.com> <0800a5ca-3d14-c541-1a1a-2574ec802b8c@fleshgrinder.com> <83fa661e-2d3d-6548-a506-fb969be31c0e@garfieldtech.com> In-Reply-To: --uSSDkoAHDW3XDg9PP4RVwxMo1gT1Q2DmV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable First a general comment on cloning. Nothing bad happens if we allow cloning other than a performance hit. But only if we ensure that immutable objects are identified by value and not by the usual object hash. In case of the latter, as it is implemented right now, you end up with an exact copy but different, due to the usual object hash. Now this might not be as bad as it sounds but it kind of makes the hole point of having immutable value objects less useful. And heck, we want a proper implementation of this. Hence, even if we allow cloning, at least an E_INFO should be emitted if done so in order to be able to spot those useless cloning operations in your code easily. Note that changing an existing class to an immutable class is always a breaking change, no matter what. Simply because you do not know what the libraries and applications that depend on your library are doing with that class right now. ;) All of this are reasons why I generally make the __clone callback of my value objects private or protected. It ensures that nobody is able to clone them without running into problems. It's all about encapsulation and only providing the behavior for the objects that is required. I am and will be a strong proponent of disallowing cloning on immutable objects. There is not a single argument why this should work. On 9/7/2016 8:57 AM, Micha=C5=82 Brzuchalski wrote: > AFAIK CoW in case of objects would be impossible to implement. >=20 Nothing is impossible. :) We have full access to the real object inside of zend_std_write_property and can easily clone it, perform the desired changes and return without affecting anyone. I am not 100% sure how to do this without fiddling around a bit. @nikic and @afaults: I am really sorry to bother you both but you guys simply know the PHP source endlessly good. What do you think, would it be possible to implement copy-on-write for an object as we have it with our scalar and compound types? final class A { public $p; } $a =3D new A; $b =3D $a; var_dump($a =3D=3D=3D $b); // bool(true) $b->p =3D 1; var_dump($a =3D=3D=3D $b); // bool(false) It's only about writing to existing properties. --=20 Richard "Fleshgrinder" Fussenegger --uSSDkoAHDW3XDg9PP4RVwxMo1gT1Q2DmV-- --U15qowMBUrfWgXNbmPNgRVWoS7T8w99fT 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 iQIcBAEBCAAGBQJX0FhNAAoJEOKkKcqFPVVr0UYP/2z8bngHNs+069XRKUXcGrag C29pDuB62E3+i4mp8jzLwtROSWBhkhmsUBOEhIgm20I/NgRJzaCB2INCsxLUDHNF Br0aSQecETFf6ORGa4lVAYlOEaO1q5R2dPBBXJpIj4bfDdnO+JAPirAghF0x2bPL LIZyRfg3zdfec0w2WfDs/ZIKN+/RIJC93srKsF/blV5iwAjujqIQa8Y9WWcumeh8 d+nyGnpv7XYSskabbjgF1EngU8bMPh3TKE7oZO8+0+IY44hPwHjyBdsNphjgyCC8 Y/AzzwYXDVy1XSrItYEJ3XE3/Pm0pHy9b8jEUmEsW9sOvaQAqiwMxomr6cImz7TU 8bdGDvwMXki4pq5xa/BkSOwQkn7SEJePUbEgPNVp2c8uhpRYb1c66BcH6v84ABBK /Yvnv7FmjuToRh+pKhMz26Vtz34hzT6ySbYcI7VNdRV3/eZptSBJc7gWhqkrJtI7 9ooR9qnCnOPSlHvJvVe9LFW75eB9ahcBALdSsS2T0sNTDuGpX23P/B8WNI8p3hZM jqwdIdFDRzgIXRJMo5cRM7CrjOtHj2mbtNj4G/tSXRB5z0IQabzhsa/y/b175h4H 81YB5HAZ/F0pEBDPhwOLW5uul4ubc6YcGY+hfrz/Tws5/7suAH9ekAp7ShBMZ4Bi KlH97uqizC0bi+4ZK7xN =mibt -----END PGP SIGNATURE----- --U15qowMBUrfWgXNbmPNgRVWoS7T8w99fT--