Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97361 Return-Path: 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 ; 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?= , Larry Garfield Cc: PHP Internals List References: <1807f949-81d3-f2c4-8706-0fdade3ea51d@garfieldtech.com> <4635ac4b-844a-b023-5ad9-e8524a156404@texthtml.net> 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: 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 : > >> 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