Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95600
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAA69SC5BAK5U0iGLZDQ084HjnWpxZiCDXWV_dDLcern_=2WiPg@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>
 <CAA69SC5BAK5U0iGLZDQ084HjnWpxZiCDXWV_dDLcern_=2WiPg@mail.gmail.com>
Date: Sat, 3 Sep 2016 16:00:36 +0100
Message-ID: <CABHuAWx64sz44LvQ0ONU5cDa7mAgwYnCUL2CPco2reOAs0EaPg@mail.gmail.com>
To: =?UTF-8?Q?Silvio_Mariji=C4=87?= <marijic.silvio@gmail.com>
Cc: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal.brzuchalski@gmail.com>, 
	Larry Garfield <larry@garfieldtech.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1146a0dcad922f053b9bb5a3
Subject: Re: [PHP-DEV] RFC - Immutable classes
From: t.carnage@gmail.com (Chris Riley)

--001a1146a0dcad922f053b9bb5a3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2 September 2016 at 15:59, Silvio Mariji=C4=87 <marijic.silvio@gmail.com=
>
wrote:

> 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@gmail.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 regardin=
g
> > >> __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.n=
o>:
> > >>
> > >>>
> > >>>> On Sep 2, 2016, at 09:10 , Silvio Mariji=C4=87 <marijic.silvio@gma=
il.com
> >
> > >>>
> > >>> 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 thin=
k
> > 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 t=
he
> > 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 t=
hat 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 jus=
t
> > 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), wa=
s
> > 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 no=
t
> > 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 surprisingl=
y
> > cheap.
> > >
> > > For language-level immutable objects, we would need some equivalent o=
f
> > 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
> > >
> >
>
>
>
> --
> Silvio Mariji=C4=87
> Software Engineer
> 2e Systems
>

The issue with handling updates on clone to immutable objects was the
reason I left the proposal to fade away last time.

Your RFC is fairly close to what I originally had in mind with some small
tweaks. To sum up what my proposal was:

- Properties can be declared immutable. Immutable properties may only be
changed under two circumstances: a) In the objects constructor b) If they
are null (This enables setter injection if required)
- Classes can be declared immutable. This is a short hand for making every
property immutable but also prevents any dynamic properties (eg not
declared at compile time) from being set outside of the constructor.
- Arrays assigned to immutable properties would not be possible to change
- Objects assigned to immutable properties would be possible to change, so
long as the same object remained assigned to the property.

The two key differences between my ideas and your current RFC are 1) No
limitation against assigning mutable objects to immutable properties 2)
Allow setting of properties which are currently unset (eg null) at any
point.

From a developer adoption point of view, I think these two points are
important to making immutable classes generally useful. Without 1, it will
be a nuisance to use 3rd party libraries esp those which retain
compatibility for PHP < 7.2. Without 2 you block the ability to use setter
injection, which I personally would be in favour of if it meant that devs
stopped using it - it wouldn't - they would simply not use immutable
classes, loosing the benefits thereof.

Dealing with the clone issue some of my ideas since then were:

- Seal/Unseal (As per Larry's suggestion)
- Parameters to __clone; in this instance the clone method would be allowed
to change properties of the object as well as the constructor. This feels
like it may breach the principal of least surprise as cloning an object no
longer guarantees an exact copy.
- A new magic method __mutate($property, $newvalue) called instead of a
fatal error when a property is changed. This probably lays too many traps
for developers for it to be a good idea.
- Implicitly returning a new object whenever a property is changed. Similar
reservations to the above.
- A new magic method __with($newInstance, $args) and a keyword with that is
used in place of clone eg $x =3D $y with ($arg1, $arg2); in this instance,
__with receives a clone of $y (after calling __clone) and an array [$arg1,
$arg2] the with magic method is allowed to mutate $newInstance and must
return it. This is currently my favoured solution

~C

--001a1146a0dcad922f053b9bb5a3--