[RFC] Readonly properties

> On Mon, Jun 7, 2021, at 4:06 AM, Nikita Popov wrote: > > On Sat, Jun 5, 2021 at 6:51 PM Larry Garfield <larry@garfieldtech.com> > > wrote: > > > > Thank you for the detailed analysis in the rationale section. I am, > > > however, still skeptical of this approach, for a couple of reasons. > > > > > > 1. This does appear to address the "leakage" problem I noted in my > earlier > > > analysis around the start of the year, when considering the writeonce > > > proposal[1][2]. That's great to see. > > > > > > 2. It doesn't address the larger question of cloning, however. The > answer > > > for now seems "maybe we'll get clone-with at some point", which would > be a > > > way around it, but there is no active RFC for that right now. I'm > > > obviously very in favor of RFCs that complement each other to give more > > > than the sum of their parts, but those RFCs need to be at least on the > > > horizon to actually come together. Right now that looks like it won't > > > happen this cycle. Absent clone-with, readonly would be effectively > > > unusable in any evolvable object of any non-trivial complexity. > > > > > > Compared to the general area of applicability of readonly properties, the > > cases that require clone-with are rare. It's the intersection of > > "not-really-immutable objects using wither evolution" and "has so many > > properties that passing them to the constructor is infeasible". While > this > > intersection does include a couple of prominent examples, they are by no > > means numerous. While it may be a problem worth solving, I *personally* > > don't consider it neither particularly important nor time critical. > > > > For what it's worth, I believe Mate wants to work on clone-with once this > > RFC passes -- while there is no RFC for that, there is already an > > implementation, though from a cursory look it would require some > > adjustments to actually work with readonly properties. > > I look forward to it. > > I don't think the use cases for non-trivial structs (where a withX() > method can just return new static(list all properties here) ) are as few as > you think. One difficulty in determining that is that, if they are made > easier/more robust (via any of the mechanisms under discussion), their > usage is likely to increase. That's a good thing, and a benefit of all of > these pieces floating around, but it does make it harder to gauge the > net-use of any particular feature. I prefer to err on the side of enabling > more flexibility and power rather than less. > > > > It also wouldn't work with objects that need properties that are not > > > constructor arguments, such as PSR-7 type objects. That's a no in my > book. > > > > > > > I don't understand what you mean here. Why would properties that are not > > constructor arguments be a problem? > > Without clone-with, if you wanted a with-er method, it would necessarily > look like this: > > class Point { > public function __construct( > public readonly int $x, > public readonly int $y, > public readonly int $z, > ) {} > > public function withX(int $newX) { > return new static($newX, $this->y, $this->z); > } > } > > That is, you're populating the entire property set via the constructor. > In some cases that's fine; the larger the object, though, the more > needlessly verbose redundancy that has. > > Now let's add a "rendered" flag property, that is public readonly bool. > (Maybe not the best example; it's before 9 am and I'm trying to think on > the fly here.) It's not in the constructor, but for later processing. It > would get set as a side effect of some other method, to indicate the point > has already been drawn. Now make a new version of the object with a > different Z. What do you do with $rendered? > > > > 3. As noted in my previous analysis, even with clone-with, asymmetric > > > visibility results in a nicer syntax when evolving objects that have > any > > > complexity to them. (See the examples in [2].) > > > > > > > I tend to agree. And I am not opposed to having asymmetric visibility as > > well. For example, C# does both, and I think both do have value. > "readonly" > > is a very strong signal to the reader. Asymmetric visibility is not. > > Asymmetric visibility (without proper readonly support) could mean that > the > > property is actually readonly, or it could mean that it's exactly what it > > says on the tin: The property is internally mutable. I don't think these > > two concepts should be conflated, though they certainly have overlap. > > I think this is the crux of the disagreement. There's a large swath of > cases that could be well-handled by either. I feel the cases that are only > or better handled by asymmetric visibility is larger than the cases that > are only or better handled by readonly. As noted above, I don't know that > either of us have any data with which to determine which is actually the > case. > > (Maybe someone with more C# experience can speak to that? What's typical > there, where both mechanisms are available?) > > > > 5. I would have to experiment a bit with hydration, as others have > noted, > > > because unconventional object construction mechanisms are a critically > > > important workflow. The RFC even notes in passing that serialization > is > > > possibly made complicated. Just how complicated? There's no mention > of > > > __deserialize() and how it would interact, but cases like that need to > be > > > very clearly handled and documented. > > > > > > > The RFC notes in passing that *if* readonly default values were allowed, > it > > could have impact on userland deserialization. As-is, I believe the > > proposal doesn't present any problem for userland hydrators or > > deserializers, or PHP's own unserialization mechanisms. This should get > > mentioned in the proposal, though it will be along the lines of "yes, > > everything works as expected". > > > > > > > 6. I'm OK with the approach to constructor promotion and default > values. > > > That seems reasonable in context, especially if combined with > > > New-in-initializers[3], which I am hoping you plan to finish this > cycle. :-) > > > 8. Although the RFC says it does not preclude accessors or explicit > > > asymmetric visibility in the future, and I absolutely believe that > Nikita > > > is genuine about that, I am still concerned that should more robust > > > proposals come forward later, it will be met with "we don't need > another > > > still-fancier syntax here, readonly is good enough." It's good to know > > > that C# manages to have both, but that doesn't mean the same logic > would > > > apply in PHP, or to PHP voters, specifically. > > > > > > > To clarify, I think your argument here goes roughly like this (correct me > > if I'm wrong): If we already have one of readonly properties or > asymmetric > > visibility, an argument could be made for not adding the other one > because > > it doesn't provide sufficient marginal value. So, if we assume that we > can > > only have one of these features, is readonly properties the right one to > > add? Shouldn't we add asymmetric visibility instead, which can be used > for > > a wider range of use cases? > > That is essentially correct. I know you're not making that argument, and > I'm not making that argument, but it's an argument I can absolutely see > being made, because it has been in the past for other things, and sometimes > I agree with it as it can be a valid argument. > > Hence why, in general, I prefer to go with the more robust, more > "interacts nicely with other things" option from the get-go, to both not > make more robust options harder to adopt in the future and to avoid user > confusion down the road when they have 3 different tools that all do > *mostly* the same thing and aren't sure of the subtle reasons why they'd > use one over the other. > > (Like, for example, if one had a readonly property but wanted to convert > it to a custom accessor property... what are the subtle knock on effects > they have to account for, then? There are almost certainly more of them > than if switching a property from implicit accessors to explicit accessors, > although off hand I don't know what they would all be.) > > > I think this is a legitimate concern to have, but (under the assumption > > that we can have only one) it's not easy to say which would be > preferable. > > Yes, asymmetric visibility is more widely applicable, but at the same > time > > I would expect most applications to be bonafide readonly properties. So > > while asymmetric visibility is more widely applicable, it's also > imprecise > > for the majority use case. Which is better? Of course, my assumption here > > could also be wrong. > > As above, I'd love to get some actual data from the C# community on this. > Lacking that, we're all just guessing.>

> Good morning Larry, > > Thank you. Very good summary, maybe worth adding to the RFC :) > > On Wed, Jun 9, 2021 at 11:52 PM Larry Garfield <larry@garfieldtech.com> > wrote: > > > readonly would be a separate, independent feature/syntax. > > Yes, my thought is about self explanatory syntax matching common usage > of the same syntax/keyword with other languages. In this case, > readonly, it does not :) > > Absolutely not a big deal (one will google that more ;), however I do > like some "consistency" across languages as we almost all rely on many > and get used to syntax for very standard operations like this. >

> > Hi Larry, > > Thanks for the response. > > > On Jun 9, 2021, at 12:51 PM, Larry Garfield <larry@garfieldtech.com>

> > > > Pierre and Mike: > > > > "Asymmetric visibility" as we keep referring to it would mean the

> > > > That is, it would let you define public/private/protected for get and

> > > > There are three key differences between readonly and asymmetric

> > > > * Asymmetric visibility would allow a property to be reassigned

> > When I read your statement I first thought you were wrong, but then I

> > I wonder if I was the only one who read that mistakenly? > > Anyway, have either you or Nikita considered making a distinction between

> On Mon, Jun 28, 2021, at 11:17 AM, Nicolas Grekas wrote: > > > > I'd like to open the discussion on readonly properties: > > > > https://wiki.php.net/rfc/readonly_properties_v2 > > > > > > > > This proposal is similar to the > > > > https://wiki.php.net/rfc/write_once_properties RFC that has been > > > declined > > > > previously. One significant difference is that the new RFC limits the > > > scope > > > > of initializing assignments. I think a key mistake of the previous > RFC > > > was > > > > the confusing "write-once" framing, which is both technically > correct and > > > > quite irrelevant. > > > > > > > > Please see the rationale section ( > > > > https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how > this > > > > proposal relates to other RFCs and alternatives. > > > > > > > > > > I plan to open voting on this RFC soon. I don't think there's anything > > > technical left to address here, the discussion mostly comes down to a > value > > > judgement. I think everyone has made their position regarding that > clear... > > > > > > > Actually, we talked off the list about a way to possibly make this work > > with __clone(): > > > > We could allow __clone to have one argument, the object being cloned. And > > when the signature declares this argument, then all readonly properties > > would be set as uninitialized on $this. > > > > A typical __clone function would look like this with readonly properties: > > function __clone(object $original) > > { > > $this->readonlyProp = clone $original->readonlyProp; > > } > > > > That would turn my vote into a +1 if that could be made to work! > > That sounds like it would support deep cloning, but not with-er methods. > There's no way to provide a changed value. It also would mean a lot of > work on larger objects to transfer across all the properties. I don't > really see what this would add. >