Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108743
User-Agent: Cyrus-JMAP/3.1.7-947-gbed3ff6-fmstable-20200220v2
Mime-Version: 1.0
Message-ID: <6bcbf0a5-92d8-4cfa-a00f-e0e967fc037e@www.fastmail.com>
In-Reply-To: 
 <CALKiJKpt+xBwyEn-yVY6h_DT-c+T6nUGgye6Ocxjdcpc4fOobg@mail.gmail.com>
References: 
 <CAH5C8xVYFkgyW88332ei8coMOijuynHXg3A2dL50XU4HP5Vpyw@mail.gmail.com>
 <CAKuGYLTsK2h_Yeo1vMju867hhmzyHt+GwoGStcQtiYMi2VB1tg@mail.gmail.com>
 <CAF+90c9RKf5PUQY0XHf=8QVVMw8jiJ=7eWfY5TTANEYt-a-ZAA@mail.gmail.com>
 <8545d15e-ddd5-42be-8405-09697a077234@www.fastmail.com>
 <CAH5C8xWgkUCAJguwnP69VqWXUaR+QtJRPMyBdv7B5vcnQjTD1g@mail.gmail.com>
 <4d9688fe-cc57-44af-903e-05f4cbb1bbcc@www.fastmail.com>
 <CALKiJKpt+xBwyEn-yVY6h_DT-c+T6nUGgye6Ocxjdcpc4fOobg@mail.gmail.com>
Date: Mon, 24 Feb 2020 14:35:15 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Feb 24, 2020, at 7:55 AM, Rowan Tommins wrote:
> On Fri, 21 Feb 2020 at 23:18, Larry Garfield <larry@garfieldtech.com> wrote:
> 
> > The with*() method style requires cloning the object.  What happens to the
> > locked status of a set property if the object is cloned?  Are they then
> > settable again, or do they come pre-locked?
> >
> > Neither of those seem good, now that I think about it.  If they come
> > pre-locked, then you really can't clone, change one property, and return
> > the new one (as is the standard practice now in that case).  If they don't
> > come pre-locked, then the newly created object can have everything on it
> > changed, once, which creates a loophole.  I'm not sure what the right
> > answer is here.
> >
> 
> 
> As with typed properties, I wonder if there's a way we can introduce a new
> initialisation sequence for objects, so that there's a specific point where
> the object is considered "fully constructed" after new or clone.
> 
> A couple of brainstormed ideas, with plenty of downsides I'm sure:
> 
> An explicit finalise() function or keyword
> 
> public function withFoo($foo) {
>     $inst = clone $this;
>     // all readonly properties are initially "unlocked"
>     $inst->foo = $foo;
>     // now lock them, perhaps also checking that no typed properties are
> left uninitialised
>     finalise($inst); // or finalise $inst;
>     return $inst;
> }
> 
> A special code block:
> 
> public function withFoo($foo) {
>     $inst = clone $this {
>         // all properties are "unlocked" within this special block
>         $inst->foo = $foo;
>     };
>     // from here onwards, readonly properties can't be written to
>     return $inst;
> }
> 
> Perhaps could also be used with constructors:
> 
> public function createFromOtherThing(OtherThing $other) {
>     $inst = new static('some parameter') {
>          // readonly properties can be written in the constructor, or
> within this block
>          $inst->foo = $other->getFoo();
>     };
>     // object is "finalised" when the block ends
>     return $inst;
> }

If the way to resolve this question is a special "unlocked" mode, I would definitely favor the explicit code block.  That way it's self-closing and you can't forget to do so.  (Murphy's Law: If you rely on developers remembering to do X to keep code safe, they will promptly forget to do X.)

Also, FTR, any approach that forces developers to write a 9 parameter constructor over and over is one I can never get behind, doubly so for something that is currently only a single line.  This isn't a case of "pain tells you what not to do"; a value object having a lot of internal properties is a completely valid use case, and "but composition" is not an answer.

--Larry Garfield