Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95702
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <83fa661e-2d3d-6548-a506-fb969be31c0e@garfieldtech.com>
References: <CAA69SC5w-0KAGcX_akmhtFJL=mte+3ZrShKPtnWgcML+z-HhKw@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> <CABdc3WoGW11+x7OLWSxEpzqc3-c2MSTC8CWVfUpybdqNzbQRBA@mail.gmail.com>
 <CABdc3WqGZ9GML-jb31FPudkML9eojpJ-Ap3kPsyd_5d8_fnwAQ@mail.gmail.com>
 <642a6e78-90ea-cbf0-ec1c-376c24e568c5@fleshgrinder.com> <CABdc3WqGFyM23CNA0eaMAyCn8L0=TaUf3xSoBOsFY_Gz4Z5uGA@mail.gmail.com>
 <CABdc3WqdTOid2BTGfpyVmNAca_9roxxx6AaQhKUPSYownO8MsA@mail.gmail.com>
 <0800a5ca-3d14-c541-1a1a-2574ec802b8c@fleshgrinder.com> <83fa661e-2d3d-6548-a506-fb969be31c0e@garfieldtech.com>
Date: Tue, 6 Sep 2016 20:33:42 +0200
Message-ID: <CAA69SC4=BXomSjmwm_6AEQGWqQqDC9scCVfv0aDH_rXMdZwt2A@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c11ce52492856053bdb09c8
Subject: Re: [PHP-DEV] RFC - Immutable classes
From: marijic.silvio@gmail.com (=?UTF-8?Q?Silvio_Mariji=C4=87?=)

--94eb2c11ce52492856053bdb09c8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

@Larry,
Fact that $this in transformer method represents clone and the original
object was my biggest concern, but again if you look at t from a point of
view where that method describes transformation it doesn't look that bad.
My initial idea was to introduce copy() method which would take as a first
argument immutable object and as a second array of parameters which are
going to be changed.

If we decide for transformer method as a solution, I don't think it has
much sense to allow cloning immutable object from user land.

I think we can live with the fact that they are mutable only in a
controlled way. But the fact that some solution for cloning is here is a
great deal since that was issue from the day 1.

Cheers,
Silvio.

2016-09-06 18:01 GMT+02:00 Larry Garfield <larry@garfieldtech.com>:

> On 09/05/2016 11:37 AM, Fleshgrinder wrote:
>
>>
>> On 9/5/2016 10:26 AM, Micha=C5=82 Brzuchalski wrote:
>>
>>> I had a talk at Room11 and we discussed idea of `mutator` keyword.
>>> There were some concerns using `mutator` as a keyword - that's because
>>> immutable object is not being muted and also magically appeared `$clone=
`
>>> would be confusing. There's an idea of creating clone before function
>>> begins
>>> and operating simply on `$this` while it's newly created clone from
>>> immutable
>>> object instance and the additional keyword for such method would be for
>>> eg.
>>> `transformer`, so basically it may look like this:
>>>
>>> immutable class Money {
>>>      public $amount =3D 0;
>>>      public $currency;
>>>      public function __construct($amount, $currency) {
>>>          $this->amount =3D $amount;
>>>          $this->currency =3D $currency;
>>>      }
>>>      public transformer function amount($newamount) {
>>>          $this->amount =3D $newAmount; // $this actually is newly creat=
ed
>>> clone
>>>          return $this;
>>>      }
>>> }
>>>
>>> $oneHundret =3D new Money(100, $eur);
>>> $twoHundret =3D $oneHundret->amount(200);
>>>
>>> How about that?
>>>
>> The thing about mutator is only partly true because setters are
>> generally just called mutator, it does not state anything about how it
>> mutates something. Note that the keyword might proof useful in
>> nonimmutable classes too for other use cases in the engine. Hence, I
>> would not throw it off board just yet.
>>
>
> Naming things is hard. :-)  While working on PSR-13 for FIG, we ended up
> with the name "evolvable" for interfaces with the withFoo() methods.  I a=
m
> not necessarily endorsing that as the best term (we weren't super happy
> about it but it was better than the alternatives), but providing it as a
> data point.
>
>
> It is true that $clone might come as a surprise and that's why I
>> proposed to pass it as the first argument to the mutator function.
>> However, you were right that that is a suboptimal proposal (and it
>> pretty much goes completely against my previous paragraph).
>>
>> However, always providing $this as a clone is also not a good idea
>> because you might want to return the same instance. This really depends
>> on the kind of action that is desired.
>>
>> It's probably much simpler to keep the clone requirement and unseal the
>> clone while making the __clone method protected by default.
>>
>>    immutable prototype {
>>
>>      protected function __clone();
>>
>>    }
>>
>>    immutable class Money {
>>
>>      public $amount;
>>
>>      public $currency;
>>
>>      public function __construct(int $amount, Currency $currency) {
>>        $this->amount =3D $amount;
>>        $this->currency =3D $currency;
>>      }
>>
>>      public function withAmount(int $amount) {
>>        if ($this->amount =3D=3D=3D $amount) {
>>          return $this;
>>        }
>>
>>        $clone =3D clone $this;
>>        $clone->amount =3D $amount;
>>
>>        return $clone;
>>      }
>>
>>    }
>>
>> This might seem like we haven't achieved much compared to the current
>> state of affairs but we actually did:
>>
>> 1. No introduction of additional keywords (besides immutable)
>> 2. No surprises (magic $clone variable)
>> 3. No hard limitation on cloning (but disallowed by default) *
>> 4. Full freedom to developers when to clone
>> 5. Full freedom to developers what to return
>>
>> * Simply because a hard limitation is not required. Let people clone the
>> immutable instances if they want too. Nothing bad happens besides
>> wasting performance.
>>
>> I think that this is the simplest and thus best solution. :)
>>
>
> How big of a need is it to allow returning $this instead of $clone, and/o=
r
> can that be internalized somehow as well?  With copy-on-write, is that
> really an issue beyond a micro-optimization?
>
> As an end-user/developer, it's unclear to me how I'd know visually what
> scopes an object can be modified in.  Basically, in the above example
> there's an implicit unlock-on-clone and lock-on-return. There's no clear
> indication of that, however, since there's no extra keywords.  Is that
> sufficiently obvious for developers?  I fear not.
>
> Also, would the above still allow for custom clone() implementations on a=
n
> immutable object or no?  I' not sure off hand which I'd prefer, honestly.=
..
>
> Another note: This would preclude "externally immutable" objects, eg, one=
s
> that can compute and internally cache a value but are still effectively
> immutable as the outside world sees them.  That's probably acceptable sin=
ce
> the manual way is still available, but I thought it worth calling out.
>
> I definitely like any of these options better than an explicit user-facin=
g
> lock/unlock mechanism, as that's begging for abuse, confusion, and
> inconsistency.
>
>
> --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

--94eb2c11ce52492856053bdb09c8--