Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108735
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> <CADyq6sL=g8jSuE3mW2sMYwXXhyVGyon1QE5yQm8AibD3ii6XSA@mail.gmail.com>
 <135A46A4-9210-4FDF-AD48-460F3F7B14AC@gmail.com>
In-Reply-To: <135A46A4-9210-4FDF-AD48-460F3F7B14AC@gmail.com>
Date: Mon, 24 Feb 2020 09:25:18 +0100
Message-ID: <CADyq6s+EE==f12OMEvp-nVA9Ti_5c+U0=CHo1HbtXVscLJzCgw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005ae77a059f4e1d4c"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties
From: ocramius@gmail.com (Marco Pivetta)

--0000000000005ae77a059f4e1d4c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 24, 2020, 09:19 Rowan Tommins <rowan.collins@gmail.com> wrote:

> On 24 February 2020 03:26:19 GMT+00:00, Marco Pivetta <ocramius@gmail.com=
>
> wrote:
> >The solution is trivial: don't use cloning:
> >
> >final class Foo
> >{
> >    public function withBar($bar):self {
> >        $instance =3D new self();
> >        $instance->foo =3D $foo;
> >        // more assignments here - unavoidable
> >        return $instance;
> >    }
> >}
>
>
> This works fine on paper, but is completely impractical as the class
> grows. Consider a class with 10 such properties


Yes, considered it: it's fine.

Also, the best approach would be to have a ctor with those 10 properties.


It's also impossible to use with inheritance, or to compose with traits (as
> Diactoros does, for instance)


Inheritance would be ditched in favour of even more composition, but even
then, inheritance is not a massive issue, especially when it comes to value
types.

Probably a couple hours of work to make a full PSR-7 implementation with
the old tests running, and the new approach applied =F0=9F=91=8D

For things that are more sensible, like a UUID, a Domain Event or a
Command, this is really a game changer anyway.

The good old Object Calisthenics rules do really apply.

--0000000000005ae77a059f4e1d4c--