Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95571
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABdc3Wpk-PypKgOjr4yUj+gyfFkssbL=fusqaUoH4-y6SbO+5w@mail.gmail.com>
References: <CAA69SC5w-0KAGcX_akmhtFJL=mte+3ZrShKPtnWgcML+z-HhKw@mail.gmail.com>
 <CAA69SC7b8csswSjGYthiR=fmy+vkgoZA9AFsp=+ikFHBh13Wtg@mail.gmail.com>
 <CABdc3Wpbsvw+4Bx9zyrDz55wAKO7PxSK=v+KeP7N9UEiyyqhnA@mail.gmail.com>
 <CAA69SC7h46FXhVovkN3nn1WU3Y=oVmcFMjio5EObZP2M3iHhmA@mail.gmail.com>
 <167d6432-e4d6-d87d-5d31-d3d82a8de4ce@fleshgrinder.com> <CAA69SC52t7n7aSWy4VVUhU9yjtkku3rv1WBCkVwy_N0RxXpEbA@mail.gmail.com>
 <CABdc3WoH8hHgiaRprszRkJWKk8gQijrxMrM95AWh3V3c41Oraw@mail.gmail.com>
 <99F80C06-654D-4109-BE07-2FA5B1073E5D@ez.no> <CAA69SC71Zx4ooS2pNnH+aSR+D1fxxtFA+zfZLKpFVvUh635t1g@mail.gmail.com>
 <4f54308a-4a69-2e6b-2ed0-51d4336d1cd4@fleshgrinder.com> <5969d1af-48e5-1376-07fe-9568de538145@texthtml.net>
 <CABdc3Wp13y2bjC-T3PuiXLvN_3rvenQ3J9f0562+xu4Yij70wg@mail.gmail.com>
 <CAA69SC45Qva3-fky+P_Bbq2rw9F5ThJQ7NzbANa2ZpZFXvMOXw@mail.gmail.com>
 <A722888E-EB21-4467-A5C0-3201A6773E1D@ez.no> <CAA69SC48nvQ9n6h088LsQ=zzo-z07fH31MQKzh9k5TFh7KGLKw@mail.gmail.com>
 <f5af9b78-eac0-651f-6740-6b5f1f0803a8@garfieldtech.com> <CABdc3Wpk-PypKgOjr4yUj+gyfFkssbL=fusqaUoH4-y6SbO+5w@mail.gmail.com>
Date: Fri, 2 Sep 2016 16:59:07 +0200
Message-ID: <CAA69SC5BAK5U0iGLZDQ084HjnWpxZiCDXWV_dDLcern_=2WiPg@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal.brzuchalski@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1144981e8814fd053b8792d1
Subject: Re: [PHP-DEV] RFC - Immutable classes
From: marijic.silvio@gmail.com (=?UTF-8?Q?Silvio_Mariji=C4=87?=)

--001a1144981e8814fd053b8792d1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Michal I'm talking about __clone() callback after clone operation. But I
agree with you about syntax part.

2016-09-02 16:46 GMT+02:00 Micha=C5=82 Brzuchalski <michal.brzuchalski@gmai=
l.com>
:

> 02.09.2016 16:29 "Larry Garfield" <larry@garfieldtech.com> 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 <andre.romcke@ez.no>=
:
> >>
> >>>
> >>>> On Sep 2, 2016, at 09:10 , Silvio Mariji=C4=87 <marijic.silvio@gmail=
.com>
> >>>
> >>> wrote:
> >>>>
> >>>> Hi Fleshgrinder,
> >>>>
> >>>> Since Michal answered most of the questions, I'll just add some note=
s.
> >>>> 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
> reason
> >>>
> >>> 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 th=
at
> >>>> 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 tha=
t the
> clone
> >>> is allowed to be modified during __clone() and afterwards sealed? Lik=
e
> 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 tha=
n
> 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 u=
se
> 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. Imagi=
ne
> 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 wort=
h
> 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 fr=
om
> public it coud gace such closure injected...
>
> > That is, outside of the object there's no way to modify it in place, bu=
t
> 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), bu=
t
> 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
> >
>



--=20
Silvio Mariji=C4=87
Software Engineer
2e Systems

--001a1144981e8814fd053b8792d1--