Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95569 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48408 invoked from network); 2 Sep 2016 14:46:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2016 14:46:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=michal.brzuchalski@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=michal.brzuchalski@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.173 as permitted sender) X-PHP-List-Original-Sender: michal.brzuchalski@gmail.com X-Host-Fingerprint: 209.85.220.173 mail-qk0-f173.google.com Received: from [209.85.220.173] ([209.85.220.173:35201] helo=mail-qk0-f173.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0E/28-19490-9D099C75 for ; Fri, 02 Sep 2016 10:46:53 -0400 Received: by mail-qk0-f173.google.com with SMTP id v123so120586144qkh.2 for ; Fri, 02 Sep 2016 07:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1KJQW97q48b0biNoQnmlRX/4bmvSdir4bJrG7o2nPsE=; b=b5WW/hYktzFrVhv+UOSoN707YPcqt6srVP6oczYV66yP09+gKjlXfLbdgYUV2gh3Z2 7he7NTjBWRKkPuEib2I0iLMA2Fkfu64VtIvBNawf9Ns4FJhbFnAojWMCVy5Irwzw3OZF gwUcGCWCIUZXbsupUb3WNi29ciouu2eG46aeHVru8H3qimvCwVKeUr28MSj5ZXzyvkx+ FnKel26ANsCyGlrwN4jwO9yuzLrJLJNBkR5GDlCf8helhWaXWZtuMz/b3yvZrYtiUXzf cm1R3xefrRltoFrOGhJkeRlc5GxZra/fGLpcEqoCNKoRXG9DYbog4W38ufdSSfM2QwRk lJKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1KJQW97q48b0biNoQnmlRX/4bmvSdir4bJrG7o2nPsE=; b=it1xfwbE0mP4cxl2NWxBEy196w36Qpu70cdYPyt6jtaAZnYqNgoRcuY2B9Cfdd+hog ukHr/tMLf8Sar0tWmVYXbGOzEZSlge72H5zfUuXDz7hI1aWkmQ0aNKtEV803DZRi/HNF 3xAtYJnlbP69NRJOgm6NwL4BCW7IAngeB/3vfMX4V2F7TZuNK+S+hdqrc22S3TeXXuGt tOMkF4xbO3toeM0tfi+C1vzlfEGn/Cz3E3xNuaJ2g/0nxQJm2UMy9o10cooFf1EmJbBI pDk41RXvoTU0K4UP580WhhnXcD1GJ5OjA14P5dDK9Z4mvZySFfvRe0X7X7L9Vgof9O3w kYjg== X-Gm-Message-State: AE9vXwPeAolt3AZUP6OCS5MwrIJbfHpQGnANTUamRxADDXJWQS70eAZ7mmqqW1uThvhsUyqGzLQLyH8yvqgBpQ== X-Received: by 10.55.181.193 with SMTP id e184mr23795630qkf.233.1472827603852; Fri, 02 Sep 2016 07:46:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.99 with HTTP; Fri, 2 Sep 2016 07:46:42 -0700 (PDT) Received: by 10.200.56.99 with HTTP; Fri, 2 Sep 2016 07:46:42 -0700 (PDT) In-Reply-To: References: <167d6432-e4d6-d87d-5d31-d3d82a8de4ce@fleshgrinder.com> <99F80C06-654D-4109-BE07-2FA5B1073E5D@ez.no> <4f54308a-4a69-2e6b-2ed0-51d4336d1cd4@fleshgrinder.com> <5969d1af-48e5-1376-07fe-9568de538145@texthtml.net> Date: Fri, 2 Sep 2016 16:46:42 +0200 Message-ID: To: Larry Garfield Cc: PHP Internals List Content-Type: multipart/alternative; boundary=94eb2c06229c24a680053b876685 Subject: Re: [PHP-DEV] RFC - Immutable classes From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=) --94eb2c06229c24a680053b876685 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 02.09.2016 16:29 "Larry Garfield" napisa=C5=82(a): > > On 09/02/2016 09:06 AM, Silvio Mariji=C4=87 wrote: >> >> Well at the moment expection is thrown in case when you try to clone >> immutable object. But you do seem to have valid point there regarding >> __clone method. I'm definitely going to give it a thought. >> >> Best, >> Silvio. >> >> 2016-09-02 15:52 GMT+02:00 Andr=C3=A9 R=C3=B8mcke : >> >>> >>>> On Sep 2, 2016, at 09:10 , Silvio Mariji=C4=87 >>> >>> wrote: >>>> >>>> Hi Fleshgrinder, >>>> >>>> Since Michal answered most of the questions, I'll just add some notes. >>>> Initially I added restrictions to abstract classes, but I did think about >>>> that over the last couple of days and couldn't find any concrete reaso= n >>> >>> for >>>> >>>> that restriction, so I think I'm going to remove that. As far as cloning, >>>> it is disabled for immutable objects, because you'll end up with the copy >>>> of object that you can not modify. I did mention in Cons sections that >>>> cloning is disabled, maybe it should be made more clear. >>> >>> >>> _If_ there are use-cases for it, wouldn=E2=80=99t it also be safe that = the clone >>> is allowed to be modified during __clone() and afterwards sealed? Like in >>> __construct(). >>> And if you don=E2=80=99t want to allow cloning, throw in __clone. >>> >>> Best, >>> Andr=C3=A9 > > > I'd have to agree here. I love the idea of "lockable" immutable objects. However, the __clone() method has to be a modifiable area just like __construct() or else it's effectively useless for anything more than a trivial object. > > This was one of the main concerns with immutability in the PSR-7 discussions. Consider this sample class, with 8 properties (entirely reasonable for a complex value object): > > immutable class Record { > public $a; > public $b; > public $c; > public $d; > public $e; > public $f; > public $g; > public $h; > > public function __construct($a, $b, $c, $d, $e, $f, $g, $h) { > $this->a =3D $a; > $this->b =3D $b; > $this->c =3D $c; > $this->d =3D $d; > $this->e =3D $e; > $this->f =3D $f; > $this->g =3D $g; > $this->h =3D $h; > } > } > > Now I want a new value object that is the same, except that $d is incremented by 2. That is, I'm building up the value object over time rather than knowing everything at construct time. (This is exactly the use case of PSR-7.) I have to do this: > > $r1 =3D new Record(1, 2, 3, 4, 5, 6, 7, 8); > > $r2 - new Record($r1->a, $r1->b, $r1->c, $r1->d + 2, $1->e, $r1->f, $r1->g, $r1->h); > > That's crazy clunky, and makes immutable objects not very useful. Imagine a money object where you had to dissect it to its primitives, tweak one, and then repackage it just to add a dollar figure to it. That's not worth the benefit of being immutable. > > The way PSR-7 addressed that (using fake-immutability, basically), was this: > > class Response { > // ... > > protected $statusCode; > > public function withStatusCode($code) { > $new =3D clone($this); > $new->statusCode =3D $code; > return $new; > } > } > I see only way in somehow invoking closere with cloning. That'll need additional syntax. Clone is left side operator not a function - it's not being called with parenthesis. If this was an object method accessible from public it coud gace such closure injected... > That is, outside of the object there's no way to modify it in place, but it becomes super easy to get a slightly-modified version of the object: > > $r2 =3D $r1->withStatusCode(418); > > And because of PHP's copy-on-write support, it's actually surprisingly cheap. > > For language-level immutable objects, we would need some equivalent of that behavior. I'm not sure exactly what form it should take (explicit lock/unlock commands is all I can think of off hand, which I dislike), but that's the use case that would need to be addressed. > > --Larry Garfield > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > --94eb2c06229c24a680053b876685--