Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97361
Return-Path: <mathieu@texthtml.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 59388 invoked from network); 12 Dec 2016 00:40:59 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 12 Dec 2016 00:40:59 -0000
Authentication-Results: pb1.pair.com header.from=mathieu@texthtml.net; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=mathieu@texthtml.net; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain texthtml.net designates 62.210.206.189 as permitted sender)
X-PHP-List-Original-Sender: mathieu@texthtml.net
X-Host-Fingerprint: 62.210.206.189 texthtml.net  
Received: from [62.210.206.189] ([62.210.206.189:42812] helo=texthtml.net)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 56/34-27518-712FD485 for <internals@lists.php.net>; Sun, 11 Dec 2016 19:40:56 -0500
Received: by texthtml.net (Postfix, from userid 65534)
	id 747BE23C; Mon, 12 Dec 2016 00:40:52 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on a0ff274cda9f
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=ham
	autolearn_force=no version=3.4.1
Received: from [192.168.0.101] (stunnel_mail_1.mail_default [172.29.0.4])
	(Authenticated sender: mathieu@texthtml.net)
	by texthtml.net (Postfix) with ESMTPA id 5E764239;
	Mon, 12 Dec 2016 00:40:21 +0000 (UTC)
To: =?UTF-8?Q?Silvio_Mariji=c4=87?= <marijic.silvio@gmail.com>,
 Larry Garfield <larry@garfieldtech.com>
Cc: PHP Internals List <internals@lists.php.net>
References: <CAA69SC7sfDOyd1oMTGF7gHLe+MXbtr4nqpQ0eufxKyWChrm9Jg@mail.gmail.com>
 <1807f949-81d3-f2c4-8706-0fdade3ea51d@garfieldtech.com>
 <4635ac4b-844a-b023-5ad9-e8524a156404@texthtml.net>
 <fa72c5af-822c-3716-f562-b069ba5ef9b8@garfieldtech.com>
 <CAA69SC477BGX-8tYGRrv-o1RYYzC3wzD-vWUWR9Gbpcz+QStxQ@mail.gmail.com>
Message-ID: <79ea244b-9fe7-5b05-d429-bf5585215542@texthtml.net>
Date: Mon, 12 Dec 2016 01:40:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.0a2
MIME-Version: 1.0
In-Reply-To: <CAA69SC477BGX-8tYGRrv-o1RYYzC3wzD-vWUWR9Gbpcz+QStxQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
From: mathieu@texthtml.net (Mathieu Rochette)



On 12/12/2016 01:16 AM, Silvio Marijić wrote:
> This have occurred to me also, I wanted to separate that into two RFC's,
> but then how we deal with RFC's that depend on each other?
well that's just my opinion but I don't think they depend on each other,
this rfc seems useful on its own. The "clone" one might depends on this
one but it does not *need* to either (otoh it certainly would be much
more useful with immutable classes than mutable classes)

plus, this part might already trigger enough discussion and adding
everything at once might get confusion. I can think of : clone, late
initialization, DateTimeImmutable and probably other subjects that could
make the discussion noisy

I'm not as familiar as you are with this mailing list so I might very
well be wrong too ^^
>
> 2016-12-12 1:03 GMT+01:00 Larry Garfield <larry@garfieldtech.com>:
>
>> Assuming this was intended for the list...
it was, thank you
>>
>> 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
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>

-- 
Mathieu Rochette