Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115265
To: internals@lists.php.net
References: <CAF+90c9kZMwjUupnCJ+Ak3SKtQSC3Mb3GTcVJWUfYG6BDkbKPA@mail.gmail.com>
 <CAOWwgpmYRgfBWxvH7j0984rSXKDM_i3jEmwo+A7=MHCa=da5BQ@mail.gmail.com>
 <c3a82f3c-2aa4-4e71-faca-782757167166@processus.org>
 <ef044022-0f12-4518-9b46-1fd54faee0f4@www.fastmail.com>
Message-ID: <e284a40e-72e2-665e-bfbf-41436a1eb592@processus.org>
Date: Thu, 1 Jul 2021 18:15:00 +0200
MIME-Version: 1.0
In-Reply-To: <ef044022-0f12-4518-9b46-1fd54faee0f4@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [VOTE] Readonly properties
From: pierre-php@processus.org (Pierre)

Le 01/07/2021 à 17:25, Larry Garfield a écrit :
> The most famous use case right now for with-er objects is PSR-7, which is where the naming convention comes from.  I cannot say how widely used it is outside of FIG-inspired value objects, but I am pretty sure it is used.
As long as you implement the with-ers manually, you don't need "clone 
with", you can create a new instance the old way (i.e. using the object 
constructor). Once there will be a "clone with" like feature, PSR's will 
be able to evolve, but right now they'll work as they are, and it's fine.
> The key point is that you rarely need to clone service objects; value objects, however, you have to clone if you want to mutate.  Look at any PSR-7 pipleline.  By design, it calls $request->withBlah($newBlah) a lot, and returns a new object.  That's the model that we want to support, and make *easier* to do, but the readonly flag makes *harder* to do than the status quo today.  (See my previous post on the subject in the last thread.)

That's the whole point of readonly properties, not to mutate. If you 
want readonly mutable properties, don't write the readonly keyword. Any 
attempt in mutating something that was explicitly closed sounds like 
you're doing something really wrong.

I mean by that that not all objects are services, value objects are 
values, they're not meant to mutate. If you need a different value, you 
use the object constructor. The right way in my opinion for PSR-7 
pipeline is to stick with the with-ers, because it makes it explicit, by 
contract, of what you are attempting to achieve in your middlewares, and 
yet still work using an interface and not an instance: this model is 
very flexible and highly extensible. And yes PSR-7 doesn't fit with 
readonly properties, but that's not a problem, having readonly 
properties doesn't mean you actually have to use them everywhere.

> There are use cases for readonly that don't require cloning.  For those, it's useful.  I personally think asymmetric visibility would render readonly unnecessary and redundant, but Nikita disagrees, and he's the one writing the code so... :-)

Yeah, I very much like asymmetric visibility as well. But readonly and 
asymmetric visibility are not incompatible. They both answer to 
different needs, some of those use cases probably intersect, but 
readonly properties have the nice advantage of allowing you to write 
pure immutable objects with a very simple syntax, and I love that, 
there's much code I wrote and do maintain that'll fit perfectly with that.

Regards,

--

Pierre