Hi Robert On Tue, Apr 9, 2024 at 9:34 PM Robert Landers <landers.rob...@gmail.com> wrote: > > On Tue, Apr 9, 2024 at 8:56 PM Larry Garfield <la...@garfieldtech.com> wrote: > > > > The Aviz RFC was put to a vote last year but didn't pass. > > It would be really nice if votes weren't just a yes/no vote, but > yes/needs-more-work/no vote, where needs-more-work and no are > effectively the same in terms of passing the RFC, but needs-more-work > just means there is more to do (either addressing ugly syntax or the > idea is sound, but as it says, it needs more work), and can thus be > simply revoted on after concerns are addressed -- instead of creating > a whole new RFC that needs to pass the "not too similar to other RFCs > rule."
The asymmetric visibility RFC did include a poll for no votes. https://wiki.php.net/rfc/asymmetric-visibility#proposed_voting_choices > I got the impression from the Aviz discussions that most people were > against Aviz due to the syntax, not the feature itself. It would be > absolutely tragic if this failed to pass simply because people > expected Aviz here. According to the poll, syntax was one, but not the primary reason for its rejection. The primary reason was that some people don't believe the feature is necessary at all. IIRC, people were arguing that readonly covers 80% of use-cases, because it protects against writes to the property both publicly and privately. I don't agree with this viewpoint, because I think readonly is bad for ergonomics. In fact, we already had an RFC that attempted to fix clone for readonly (https://wiki.php.net/rfc/readonly_amendments) but this fix was not complete (because it's still not possible to pass values from clone to __clone). "Clone with" is another thing needed to fix this, and at this point it just feels like applying more band-aids. For DTOs, I believe value types (i.e. data classes, https://externals.io/message/122845) solve the problem of "spooky actions at a distance" in a cleaner and more ergonomic way. For services and other intentional reference types, readonly often isn't the right choice either, just to make the property not publicly writable. Asymmetric visibility would be a much more fitting choice. Anyway, we didn't include asymmetric visibility in this RFC because: * We wanted to avoid getting rejected by people who fundamentally dislike asymmetric visibility. * We didn't feel it was fair to "sneak" the feature back in through some other RFC, when it was explicitly rejected. Instead, we are planning to re-propose asymmetric visibility once property hooks are merged, as it may become more apparent why it is useful. Ilija
