Re: [PHP-DEV] [VOTE] Readonly properties

This is only part of a thread. view whole thread
  115262
July 1, 2021 15:25 larry@garfieldtech.com ("Larry Garfield")
On Thu, Jul 1, 2021, at 9:49 AM, Pierre wrote:
> Le 01/07/2021 à 16:38, Nicolas Grekas a écrit : > > Hi NIkita, > > > > I voted against the proposal because it doesn't work with cloning at all. > > > > Cloning is a critical feature of stateful objects, and we should solve it > > the same version that introduces readonly IMHO. > > > > If we figure out that we can't agree on a sensible improved behavior for > > cloning, we're going to be in a dead-end with readonly. > > > I respectfully disagree. > > Having readonly properties and immutable objects is a must have, but > changing property of an object while cloning, not so much. There's many > case where readonly properties will be valuable where you never need to > clone your objects. Actually, cloning objects is not something you do > every day. > > Please note that I agree with you that advanced / flexible clone > semantics would be a nice to have, but I don't see the lack of it > blocking for readonly properties. > > I personally don't have any real use case where I couldn't implement > withers on my objects doing the same than dedicated advanced clone > semantics. Could you please provide some real world examples ? People > could change their minds if they could see why it's so blocking for you. > > Regards,
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. 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.) 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... :-) The best case scenario is by 8.2 we end up with asymmetric visibility and clone-with, and combined with readonly we get a huge array of options for how to lock down value objects and still make them evolvable. The worst case scenario is we find that readonly cannot be extended to support clone-with for some hand-wavy engine reasons, at which point it becomes largely vestigial in favor of asymmetric visibility and clone-with. --Larry Garfield
  115264
July 1, 2021 16:05 deleugyn@gmail.com (Deleu)
On Thu, Jul 1, 2021 at 5:25 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Thu, Jul 1, 2021, at 9:49 AM, Pierre wrote: > > Le 01/07/2021 à 16:38, Nicolas Grekas a écrit : > > > Hi NIkita, > > > > > > I voted against the proposal because it doesn't work with cloning at > all. > > > > > > Cloning is a critical feature of stateful objects, and we should solve > it > > > the same version that introduces readonly IMHO. > > > > > > If we figure out that we can't agree on a sensible improved behavior > for > > > cloning, we're going to be in a dead-end with readonly. > > > > > I respectfully disagree. > > > > Having readonly properties and immutable objects is a must have, but > > changing property of an object while cloning, not so much. There's many > > case where readonly properties will be valuable where you never need to > > clone your objects. Actually, cloning objects is not something you do > > every day. > > > > Please note that I agree with you that advanced / flexible clone > > semantics would be a nice to have, but I don't see the lack of it > > blocking for readonly properties. > > > > I personally don't have any real use case where I couldn't implement > > withers on my objects doing the same than dedicated advanced clone > > semantics. Could you please provide some real world examples ? People > > could change their minds if they could see why it's so blocking for you.. > > > > Regards, > > 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. > > 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.) > > 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... :-) > > The best case scenario is by 8.2 we end up with asymmetric visibility and > clone-with, and combined with readonly we get a huge array of options for > how to lock down value objects and still make them evolvable. The worst > case scenario is we find that readonly cannot be extended to support > clone-with for some hand-wavy engine reasons, at which point it becomes > largely vestigial in favor of asymmetric visibility and clone-with. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > I'd say don't use readonly on PSR-7. I have so many use cases for readonly
property and no use case for cloning. readonly syntax is far superior than asymmetric visibility and will be almost as good as Constructor Promotion Property. I would even go as far to say that I don't need anything more than just readonly as-is. I think the bigger picture here is how many use cases are there that would vastly benefit from this Vs how many use cases could potentially benefit from it but won't because of lack of cloning support. Of course everyone's opinion will be shaped by the universe they live in and in mine this RFC covers everything I need with no drawbacks and I honestly don't understand not wanting this just because of lack of cloning. -- Marco Aurélio Deleu
  115266
July 1, 2021 16:25 ocramius@gmail.com (Marco Pivetta)
On Thu, Jul 1, 2021 at 6:06 PM Deleu <deleugyn@gmail.com> wrote:

> I honestly don't understand not wanting this just because of lack of > cloning. >
Agreed: improvements on cloning ergonomics can come later. Also, the problem goes away the smaller your state becomes: this may encourage some design towards more granular data-structures. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  115265
July 1, 2021 16:15 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