Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108733
MIME-Version: 1.0
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> <452D962A-C588-4F04-B000-479EBEA9B9DB@newclarity.net>
 <9ebc648c-39d1-45b1-9f3d-9a799c6dec93@www.fastmail.com>
In-Reply-To: <9ebc648c-39d1-45b1-9f3d-9a799c6dec93@www.fastmail.com>
Date: Mon, 24 Feb 2020 04:26:19 +0100
Message-ID: <CADyq6sL=g8jSuE3mW2sMYwXXhyVGyon1QE5yQm8AibD3ii6XSA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000006dd44059f49f0b3"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties
From: ocramius@gmail.com (Marco Pivetta)

--00000000000006dd44059f49f0b3
Content-Type: text/plain; charset="UTF-8"

Hey Larry,



On Sun, Feb 23, 2020, 18:06 Larry Garfield <larry@garfieldtech.com> wrote:

>
> It does not.
>
> 1) Race condition if I assume that a public write-once property is a
> materialized value, but access it before it gets materialized.
>

This is alrey true for any public typed properties without default values,
and why static analysis tools pick up missing initialisation since ages.


> 2) Race condition if internal non-constructor code wants to set the value,
> but some external routine has set it first.
>

Internal ctors are part of the category above: tools like psalm pick this
up as well.



> 3) Cloning creates an interesting and complicated case of both of the
> above.  Does a cloned object start with its write-once bits reset or no?
> There's problems both ways.
>

Not a problem: we seem to be making a problem out of the pattern used in
current PSR-7 implementations, which is following:

final class Foo
{
    public function withBar($bar):self {
        $instance = clone $this;
        $instance->foo = $foo;
        return $instance;
    }
}

The solution is trivial: don't use cloning:

final class Foo
{
    public function withBar($bar):self {
        $instance = new self();
        $instance->foo = $foo;
        // more assignments here - unavoidable
        return $instance;
    }
}

--00000000000006dd44059f49f0b3--