Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112717
MIME-Version: 1.0
In-Reply-To: <6f51556b-a566-45d2-939e-3d6c3441eb00@www.fastmail.com>
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> <6f51556b-a566-45d2-939e-3d6c3441eb00@www.fastmail.com>
Date: Sat, 2 Jan 2021 22:12:05 +0000
Message-ID: <CAJpLVh0ZUppsOrB4tHz6UeWC27+0Tt3fNPGGk6RtNU_Keygo-Q@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Analysis of property visibility, immutability, and
 cloning proposals
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2021-01-02 21:25 GMT, Larry Garfield <larry@garfieldtech.com>:
> On Sat, Jan 2, 2021, at 12:56 PM, Rowan Tommins wrote:
>> On 01/01/2021 20:31, Paul M. Jones wrote:
>> > The complaints against the incomplete and inconsistent immutability of
>> > PSR-7 have merit.
>>
>>
>> The big mistake of PSR-7, in my view, is mixing immutable objects with
>> streams, which are inherently mutable/stateful. I wonder if there are
>> any lessons to be learned there in terms of what kinds of immutability
>> the language should encourage / make easy.
>>
>> For instance, is it better to constrain entire objects to be immutable
>> rather than individual properties? And should there be restrictions on
>> what you can declare as immutable, since "immutable resource" is largely
>> nonsensical?
>>
>> Or is it rather a reflection that building purely immutable
>> implementations is hard, and the language needs other facilities
>> (monads? ownership?) to mix in those parts that don't fit?
>>
>> Regards,
>
> I rarely hear that called out as a PSR-7 complaint specifically, in
> practice, but moving on...
>
> IMO, it's better to put the focus on immutable properties.  There are use
> cases where you want only some properties to be immutable, but not the whole
> class.  If you do want the whole class, then marking all the properties
> immutable is effectively the same thing.
>
> Though, again, in practice, at least in PHP, I don't think immutable
> properties should be the goal.  Asymmetric visibility lets us built safely
> immutable-from-the-outside objects that are "up to you" on the inside.  I
> think that gives us a better end result given the nature of PHP.  In other
> languages that wouldn't make as much sense, but PHP is what it is.
>
> Copy on write makes "immutable data structures" not something we need to
> build explicitly; we get "close enough" for free.  If you really wanted to
> micro-optimize the memory and CPU usage further than that... go build it in
> Rust instead.

Correct me if I'm wrong, but copy-on-write is only beneficial with
values, not references to values (objects)? When you clone with a
`with` method, you always write, so you always have to copy. And
objects are already free to pass around without any copying happening
automatically (as is the case with arrays, which have value semantics,
which is why copy-on-write was implemented to not copy needlessly when
an array is only read from).

Olle