Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112720
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
In-Reply-To: <a67b43e8-1940-686b-445a-1586d718fc8c@gmail.com>
Date: Sat, 2 Jan 2021 20:37:03 -0600
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <643FECB5-A7EE-4EDB-A473-F14971CE083F@pmjones.io>
References: <1d0abb04-4987-43a9-85bc-bccc3bd6be9a@www.fastmail.com>
 <03108284-740a-4a5d-130f-15b2e67e9df9@mabe.berlin>
 <CAJpLVh2M3iKhG8b2qZydf_70K4NYdZ5fpSEsRNK7uLeESUPHKg@mail.gmail.com>
 <459d7ff7-e553-dce9-7d43-c3b1e772e572@gmail.com>
 <CAJpLVh31UzSJvKdypQ=Mh+6CLvfUCrF==z6HBDD1_nuYqFzG5A@mail.gmail.com>
 <7f4fe9ca-1c20-6f69-cef0-a9718af742a3@gmail.com>
 <C9E7D7C8-2EB8-479A-B0BF-E992172765EE@newclarity.net>
 <30906866-1971-8395-05a0-fd78d054bb89@gmail.com>
 <CAJpLVh3c2o+RDjEg+GenLJa9rh5iLXMu8VZnbkdM0_n0FmfM=A@mail.gmail.com>
 <c9949f2e-79a7-4a35-9d0e-c8a8ba861fb0@www.fastmail.com>
 <0C621FEF-B76F-41F5-A5A8-E6F24D69DD3D@pmjones.io>
 <a67b43e8-1940-686b-445a-1586d718fc8c@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Analysis of property visibility, immutability, and
 cloning proposals
From: pmjones@pmjones.io ("Paul M. Jones")

Hi Rowan and all,

I apologize in advance for the wall-of-text; the short questions lead to =
long answers.


> On Jan 2, 2021, at 12:56, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 01/01/2021 20:31, Paul M. Jones wrote:
>=20
>> The complaints against the incomplete and inconsistent immutability =
of PSR-7 have merit.
>=20
> The big mistake of PSR-7, in my view, is mixing immutable objects with =
streams, which are inherently mutable/stateful.

(/me nods along)

Streams were noted as the one explicit exception to immutability in =
PSR-7. Looking back on it, that should have been a sign to us that =
immutability should not have been a goal.

(Re: PSR-7 but not re: immutability, there is at least one more mistake =
born of the original intent, that seemed reasonable at the time but in =
hindsight was another poor decision: it combines the concerns of the =
HTTP message with the concerns of middleware communication. This =
observation is attributable to [deleted] at Reddit ...

  =
https://www.reddit.com/r/PHP/comments/5ojqr0/q_how_many_psr7_implementatio=
ns_exist_a_zero/dcjxtxl/

... stating "[T]he true intent of PSR-7 [is] not to be an HTTP message =
standard, but to be middleware IO standard, which happens to be mostly =
(but not only) an HTTP message." It's an accurate assessment.)


> I wonder if there are any lessons to be learned there in terms of what =
kinds of immutability the language should encourage / make easy.

I think there are; I wrote about at least some of them here ...

  =
https://paul-m-jones.com/post/2016/09/06/avoiding-quasi-immutable-objects-=
in-php/

... in which I conclude that, if you want to build a truly immutable =
object in PHP, it appears the best approach is the following:

- Default to using only scalars and nulls as properties.

- Avoid streams as properties; if a property must be a stream, make sure =
that it is read-only, and that its state is restored each time it is =
used.

- Avoid objects as properties; if a property must be an object, make =
sure that object is itself immutable.

- Especially avoid arrays as properties; use only with extreme caution =
and care.

- Implement __set() to disallow setting of undefined properties.

- Possibly implement __unset() to warn that the object is immutable.

I put those conclusions (and other resulting from that article) into an =
implementation described here:

  http://paul-m-jones.com/post/2019/02/04/immutability-package-for-php/


> is it better to constrain entire objects to be immutable rather than =
individual properties?

I would say that the entire object ought to be immutable, for reasons =
that are difficult for me to articulate.


> And should there be restrictions on what you can declare as immutable, =
since "immutable resource" is largely nonsensical?


I think so, and I note some of those restrictions above. In particular, =
the immutability package ValueObject further inspects arrays to restrict =
their values to immutables as well.


--=20
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php