Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97359
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error)
To: internals@lists.php.net
References: <CAA69SC7sfDOyd1oMTGF7gHLe+MXbtr4nqpQ0eufxKyWChrm9Jg@mail.gmail.com>
 <1807f949-81d3-f2c4-8706-0fdade3ea51d@garfieldtech.com>
 <4635ac4b-844a-b023-5ad9-e8524a156404@texthtml.net>
Cc: Mathieu Rochette <mathieu@texthtml.net>
Message-ID: <fa72c5af-822c-3716-f562-b069ba5ef9b8@garfieldtech.com>
Date: Sun, 11 Dec 2016 18:03:43 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <4635ac4b-844a-b023-5ad9-e8524a156404@texthtml.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
From: larry@garfieldtech.com (Larry Garfield)

Assuming this was intended for the list...

On 12/11/2016 05:55 PM, Mathieu Rochette wrote:
> Currently the only "unlocked context" for an object is its
> constructor.  As discussed previously, that is insufficient.  For any
> non-trivial object (more than 1-3 internal properties) creating a new
> one via the constructor only when incrementally building is
> prohibitively difficult.  The pattern of with*() methods that spawn
> new objects via clone(), a la PSR-7, needs to be supported.  That is:
>
> immutable class Money {
>    // ...
>
>    public function add(Money $other) : Money {
>      $new = clone($this);
>      $new->amount += $other->amount;
>      return $new;
>    }
> }
>
> I'm not sure how easily we can denote that sort of case.  It's outside
> the __clone() function itself, which is what makes it difficult.
> Without that, though, such immutable objects are of only limited use.


>
> As you said, it has been already been discussed that a method to build
> new altered object from an existing one could be improved. Different
> options were proposed but maybe it's better to start small to get this
> first part right and add this in another rfc ? having everything at the
> same time might makes the rfc more difficult to be accepted

On the contrary, an RFC that doesn't fully solve the issue at hand and 
leaves major gaps in place is a poor RFC, and I would expect to be 
justifiably voted down.

--Larry Garfield