On Sun, 13 Nov 2022, Larry Garfield wrote: > There's two design decisions we've made at this point, both of which > we think are logical and reasonable: > > 1. If specified, the set visibility must be tighter than the get > visibility. So `protected protected(set)` and `protected public(set)` > are not permitted, for instance. > > 2. `readonly` is a "write once" flag that may be combined with > asymmetric visibility. If no set visibility is specified, `readoly` > implies `private(set)`, but a different set visibility may also be > provided. > > These are both reasonable rules. However, it creates a conflict. > Specifically, in the following cases: > > public public(set) readonly string $foo > > protected protected(set) readonly string $foo
Just to see if I understand this correctly, the "protected(set)" overwrites the implicit "private(set)" that "readonly" confers? I think that alone is confusing. > These would be the only way to have a non-private-set readonly > property. While the first is in practice quite unlikely, the second > has valid use cases. (In particular, a base class that provides > properties expected to be set by a child constructor, and then used by > a method in the parent class.) However, it would not be allowed under > the rules above. Working around it would require specifying `public > protected(set) readonly...`, which means exposing a property that > likely should not be exposed. > > That creates an odd situation where readonly and asymmetric visibility > may only be combined "sometimes." That is not deesireable. The only > way to combine them in their current form is to allow `protected > protected(set)` only if readonly is in use, which is excessively > complicated both to implement and to explain/document/use. > > We see two possible ways to resolve this conflict: > > 1. Relax the set-is-tighter restriction. That would allow `protected > protected(set)` etc. on any property. It wouldn't be particularly > useful unless readonly is being used, but it would be syntactically > legal and behave as you'd expect. We could still disallow "set is > more permissive" combinations (eg, `private public(set)`), as those > have no apparent use case. > > 2. Disallow readonly and asymmetric visibility being combined, because > readonly already has a hard-coded implied asymmetric visibility. > This option removes some potential use cases (they would most likely > drop the readonly), but has the upside that it's easier to re-allow at > some point in the future. I am in favour of this option 2. As I already think "protected protected(set) readonly" is a confusing thing to see. If I hadn't read this email, I wouldn't have understood the interacting between the "protected(set)" and "readonly". cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
