Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95617
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <0e71d28e-1d64-5372-b58d-e54c7afae3b8@fleshgrinder.com>
References: <CAA69SC5w-0KAGcX_akmhtFJL=mte+3ZrShKPtnWgcML+z-HhKw@mail.gmail.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>
 <CABHuAWx64sz44LvQ0ONU5cDa7mAgwYnCUL2CPco2reOAs0EaPg@mail.gmail.com> <0e71d28e-1d64-5372-b58d-e54c7afae3b8@fleshgrinder.com>
Date: Sun, 4 Sep 2016 14:10:37 +0200
Message-ID: <CABdc3WoGW11+x7OLWSxEpzqc3-c2MSTC8CWVfUpybdqNzbQRBA@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c08340a9de057053bad7324
Subject: Re: [PHP-DEV] RFC - Immutable classes
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--94eb2c08340a9de057053bad7324
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-09-04 10:55 GMT+02:00 Fleshgrinder <php@fleshgrinder.com>:

> Hi Chris!
>
> On 9/3/2016 5:00 PM, Chris Riley wrote:
> > - Properties can be declared immutable. Immutable properties may only b=
e
> > changed under two circumstances: a) In the objects constructor b) If th=
ey
> > are null (This enables setter injection if required)
> >
>
> The constraint b) would make the object mutable and defeat the purpose
> of the immutable modifier since any property could change at any time if
> it was NULL at the beginning. Requiring syncing in concurrent environment=
s.
>
> On 9/3/2016 5:00 PM, Chris Riley wrote:
> > - Arrays assigned to immutable properties would not be possible to chan=
ge
> >
>
> Array support would definitely be very nice. I mean, we have constant
> arrays already, hence, it is possible.
>
> On 9/3/2016 5:00 PM, Chris Riley wrote:
> > - Objects assigned to immutable properties would be possible to change,
> so
> > long as the same object remained assigned to the property.
> >
>
> This would once more lead to mutability and the constraint of
> immutability would be violated.
>
> On 9/3/2016 5:00 PM, Chris Riley wrote:
> > 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 de=
vs
> > stopped using it - it wouldn't - they would simply not use immutable
> > classes, loosing the benefits thereof.
> >
>
> The adoption of the feature will be halted until 7.2 is widely available
> in bigger projects. That is most certainly right. However, we should aim
> for the best, most useful, and future proof solution and not towards the
> one that's adopted very fast but lacks some important constraints.
> Having truly immutable objects is required in concurrent scenarios and
> such scenarios are in the future for PHP and not in the past.
>
> Regarding setter injection: I do not see the need for it at all in the
> context of immutable objects. In the end we are talking about value
> objects here and they should not have any optional dependencies. Maybe
> you could come up with a use case to illustrate the need?
>
> On 9/3/2016 5:00 PM, Chris Riley wrote:
> > 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 fee=
ls
> > 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 tra=
ps
> > 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 tha=
t
> is
> > used in place of clone eg $x =3D $y with ($arg1, $arg2); in this instan=
ce,
> > __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
> >
>
> How does one know which property is to be mutated in the __with method?
> You should also not underestimate the performance hit and the branching
> since you only want to change the properties that changed based on the
> data from the passed array.
>
> I have a third proposal after giving this some more thought. Inspired by
> Rust's approach to mark mutation explicitly.
>
>   final immutable class ValueObject {
>
>     public $value;
>
>     public mutator [function] withValue($clone, $value): static {
>       $clone->value =3D $value;
>     }
>
>   }
>
>
Providing `mutator` | `mut` keyword as method modifier sounds liek a good
idea,
althought passing `$clone` parameter as first additional param could break
method declaration and would be misleading.

Assuming mutator method is designed to  return mutated clone of immutable
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 in som=
e
circumstances ther would be also possible to return `$this`.

The return type declaration `self` could increase readability, but should
not be required,
as some developers doesn't already use return types.


> A mutator function always receives the mutable clone as first argument
> and always returns that one. Users can have a return but they must
> return the clone (hence the static return type declaration).
>
>   $vo1 =3D new ValueObject(1);
>   $vo2 =3D $vo1->withValue(2);
>
> Calls are of course without the clone as it is handled by the engine.
> There is no special branching necessary and no performance hit at all
> while the logic is kept in the place where it is required.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>


--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
brzuchalski.com

--94eb2c08340a9de057053bad7324--