Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95568 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 47194 invoked from network); 2 Sep 2016 14:45:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2016 14:45:35 -0000 Authentication-Results: pb1.pair.com header.from=marijic.silvio@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=marijic.silvio@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.50 as permitted sender) X-PHP-List-Original-Sender: marijic.silvio@gmail.com X-Host-Fingerprint: 209.85.214.50 mail-it0-f50.google.com Received: from [209.85.214.50] ([209.85.214.50:38657] helo=mail-it0-f50.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A3/F7-19490-B8099C75 for ; Fri, 02 Sep 2016 10:45:33 -0400 Received: by mail-it0-f50.google.com with SMTP id c198so41544836ith.1 for ; Fri, 02 Sep 2016 07:45:29 -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=UyjgTuI1v7VQIp8DfZ3qzv38u4NbabaiBUwRRqlFW8M=; b=piDSUOm3Q1NZwDv29ahPYVe+gfW8GQkml5aXXrxyjbtzY8BIwnfZZ4RToXwnuc5g4X shfZVaUOR+UXS1k7lBJJo88XwZx5PPpXBM5XQ/RmLl5DNbgZagVbwp5zo1nJV9/I6o2A wu8n2iptudryrWtK/X6FZB4pKcd60HH5Ge4eXXG5JA2WJGQdO8JbPu+kECk+HqutDBUX OpWXMbJURBq/j5KMS8veXqOReLoq8SpIm5cDK48kRIqlRgcWpmNeWnumFSBzpxm9aNuV 10knGMTDdeeJgCz6gpUn2Kw9P25acRJGef5BAqypgjAXv+Rwt3P8SMmUBaLNK9GBkm15 Bttg== 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=UyjgTuI1v7VQIp8DfZ3qzv38u4NbabaiBUwRRqlFW8M=; b=f7nXZ/s13ddyTCRmeFHFVCQY80FEcZu8bEZgA2edakP6m+GshRWSGQkOrsOsJ3pVet 6AzTT7B0N4ow4S+rQVzv59lhb69+f8at1JdEYyEiU3TET1zINUn/pja42H59uOS8JtWW hElXvpmH1Rs0KcH+mC3TuuoW6+A0EtJlw6DpTbf/oBpX1wMcNLNkn9KAauqaMjcMtKD9 7rhUVmJNKp3RyEcYc0YT4yWQLqRaoO7arzyHrTO6l1D0YsMVRelikg394DPWzZtgRjnp kaIEzgsYBppYAPV2dsxh2snULnIU9bc3jEVQd+fyWxMzp8FubKFLgPruwkNxO/Q1RoY3 Bnvw== X-Gm-Message-State: AE9vXwMM0efsx1fTdnl3GrkrTMVTPmB9lae9ws4WDUkOC86Y8XUUqwTTBHR4HqiTKApdAa+DGVCQyFms8NMXoA== X-Received: by 10.36.13.203 with SMTP id 194mr5103482itx.79.1472827524200; Fri, 02 Sep 2016 07:45:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.237.74 with HTTP; Fri, 2 Sep 2016 07:45:23 -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:45:23 +0200 Message-ID: To: Larry Garfield Cc: PHP Internals List Content-Type: multipart/alternative; boundary=001a11404b24653e9e053b876115 Subject: Re: [PHP-DEV] RFC - Immutable classes From: marijic.silvio@gmail.com (=?UTF-8?Q?Silvio_Mariji=C4=87?=) --001a11404b24653e9e053b876115 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Basically I'm concerned about __clone() since you can not pass parameters 2016-09-02 16:44 GMT+02:00 Silvio Mariji=C4=87 : > Hi Larry, > I'm aware of that but we do have make some strong constraints there > otherwise we are undermining the strong guarantee of immutability. I woul= d > agree to allow object modification only and only *inside* __construct() > and __clone methods. I'm trying to come up with idea how would that look > like. If you guys have some suggestions, that would be great. > > 2016-09-02 16:27 GMT+02:00 Larry Garfield : > >> 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 reas= on >>>>> >>>> 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 tha= t >>>>> 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 th= an >> 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. Imagin= e >> 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 wor= th >> 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; >> } >> } >> >> 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), b= ut >> 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 >> >> > > > -- > Silvio Mariji=C4=87 > Software Engineer > 2e Systems > --=20 Silvio Mariji=C4=87 Software Engineer 2e Systems --001a11404b24653e9e053b876115--