Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95623 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44089 invoked from network); 4 Sep 2016 20:38:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Sep 2016 20:38:47 -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.84 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.84 mx103.easyname.com Received: from [77.244.243.84] ([77.244.243.84:58833] helo=mx202.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C9/73-45301-3568CC75 for ; Sun, 04 Sep 2016 16:38:45 -0400 Received: from cable-81-173-132-156.netcologne.de ([81.173.132.156] 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 1bgeBc-0001pg-Ss for internals@lists.php.net; Sun, 04 Sep 2016 20:38:41 +0000 Reply-To: internals@lists.php.net References: <4f54308a-4a69-2e6b-2ed0-51d4336d1cd4@fleshgrinder.com> <5969d1af-48e5-1376-07fe-9568de538145@texthtml.net> <0e71d28e-1d64-5372-b58d-e54c7afae3b8@fleshgrinder.com> To: internals@lists.php.net Message-ID: <642a6e78-90ea-cbf0-ec1c-376c24e568c5@fleshgrinder.com> Date: Sun, 4 Sep 2016 22:38:27 +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="TTW5fXEnNLgw4b2bpc9WBNkBX2Hxk61JK" Subject: Re: [PHP-DEV] RFC - Immutable classes From: php@fleshgrinder.com (Fleshgrinder) --TTW5fXEnNLgw4b2bpc9WBNkBX2Hxk61JK Content-Type: multipart/mixed; boundary="h3JfUanHFItJAERsTL5L4vam7aKKlv6ig"; protected-headers="v1" From: Fleshgrinder Reply-To: internals@lists.php.net To: internals@lists.php.net Message-ID: <642a6e78-90ea-cbf0-ec1c-376c24e568c5@fleshgrinder.com> Subject: Re: [PHP-DEV] RFC - Immutable classes References: <99F80C06-654D-4109-BE07-2FA5B1073E5D@ez.no> <4f54308a-4a69-2e6b-2ed0-51d4336d1cd4@fleshgrinder.com> <5969d1af-48e5-1376-07fe-9568de538145@texthtml.net> <0e71d28e-1d64-5372-b58d-e54c7afae3b8@fleshgrinder.com> In-Reply-To: --h3JfUanHFItJAERsTL5L4vam7aKKlv6ig Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/4/2016 2:29 PM, Micha=C5=82 Brzuchalski wrote: >> Providing `mutator` | `mut` keyword as method modifier sounds liek a g= ood >> idea, >> althought passing `$clone` parameter as first additional param could b= reak >> method declaration and would be misleading. >> >> Assuming mutator method is designed to return mutated clone of immuta= ble >> object >> having `$clone` variable could be handled internally without breaking >> method declaration. >> >> Such variable could be unlocked while in mutator method and locked on >> return. >> I was thinking about additional check if such mutator returns `$clone`= but >> not `$this` >> but I don't see the need of it - assuming there is no what to change i= n >> some >> circumstances ther would be also possible to return `$this`. >> >> The return type declaration `self` could increase readability, but sho= uld >> not be required, >> as some developers doesn't already use return types. >> >=20 > It could look like in this gist > https://gist.github.com/brzuchal/e7b721e22a19cca42ec0d1f597a23baf >=20 This is exactly how I meant it, yes. I actually prefer it if the variable just exist in the context instead of passing it as first argument. It's less obvious that it exists but the same could be said about $this. Would it be possible to have this thing just in time instead of automatically created in every mutator function? public mutator function f() { if (condition) { $clone is created; return $clone; } return $this; } PS: I started overhauling the test cases and error messages and will create a PR against your branch soon. I will start with the RFC afterwards. Should I simply edit the RFC in the Wiki or should we manage this somewhere else? --=20 Richard "Fleshgrinder" Fussenegger --h3JfUanHFItJAERsTL5L4vam7aKKlv6ig-- --TTW5fXEnNLgw4b2bpc9WBNkBX2Hxk61JK 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 iQIcBAEBCAAGBQJXzIZOAAoJEOKkKcqFPVVrBfUQAKT/nXMEaDo4p4yRXhWKDBBT w9mqqB/vTj00IZ3ZUiDq8x1ZY3sZ/sRDGBWChdeJds4XrtazWaMATkWABNePOnFZ c3y8uztnd4iDu1CUZbzNRcd5mv69EcBU0VpH4nUwtdwSfj9MpIIurXZ1VJ+WmOwH 1tAif+pdYIJ4OYb3fqRKRxWpcm4MSfzu/cVXYyiZEKcTyx075k77OZlmaKS55TVR crECrU5Dh4b4dyanKOrag2S8NrGc1BzUZZg0MHWEHcc7QX4Dde6YrVLHpEw79p/g Qs7dB/RHR8lWVDPtJqh5lMgjrKtREacYHZsHcw8aRmOUAw04NzeTdAWxKZdIe9hs u7qdKqDlEBL/iDkoOqmxCshMhQJDm6ivGWo/PSRh2fDh3k52KcEKvw2aFIZvajqp lhHFDGHg8WgahxHR83MJG4Co/qnDlP5YRl2ZdEWDM395IJr0ZaZC8OK8F686Eez1 q9YjOhK61Syobd6JhddnnGNBKf3CXNtcjF5PXzC514Qt5rbaPGt2WO4O57a2z8ef rr1iOXdkf1fg1HA0oNw5LwzJCGLp2bn5FBzO31d1f2u89QBnNYsdfKYSsUDrtX7a Qy1TiQB/Fpr03WCiqjj1OzRzPLpdJeE+Ly1L/UhxH8Rfu3YIrCXNgrI9pk0ScLCG fK2TuVC68EmJ/Lkr0k6t =9jaU -----END PGP SIGNATURE----- --TTW5fXEnNLgw4b2bpc9WBNkBX2Hxk61JK--