On Thu, Dec 1, 2022, at 12:31 PM, Tim Düsterhus wrote: > Hi > > On 11/29/22 21:29, Larry Garfield wrote: >> Thank you everyone for the feedback. Based on this thread, we've made two >> changes to the RFC: >> >> 1. We've moved readonly back to forbidden with a-viz for now. I've added a >> section to Future Scope where we really should sort this out in the future, >> but we'll do that in the future when we can all focus on the various nuances >> of just that piece. >> >> 2. I rewrote the section on __set to make it clearer. That also included >> Ilija and I digging into all the nuances that are already present. The text >> may still look a bit complex, but that's because the existing logic is >> already complex with readonly. Long story short, the a-viz RFC does not >> change anything in the way __set works vis a vis asymmetric visibility; it >> just inherits and continues what readonly already started, so it's >> consistent. >> >> The PR should be updated in the next week or two with the latest changes. >> Baring any major need for change, we expect to call a vote for it shortly >> after New Years. >> > > Okay, then I'd like to officially "request" that the abbreviated form > [1] is dropped: > > I believe 'protected(set) string $foo' is easily confused with > 'protected string $foo' at a simple glance. > > Also any implicit rules are something developers will need to learn by > heart, whereas an explicit 'public protected(set) string $foo' could > reasonably be understood by someone without any PHP experience and some > basic experience of OO concepts. > > Having two separate explicit keywords also makes it much clearer that > asymmetric visibility is involved, because it's also asymmetric in the code. > > I believe the only benefit of the abbreviated form is saving 6 > keystrokes (+ one hit to the spacebar) and I don't believe it's worth > the lack of clarity for an important property of the defined property. > > Best regards > Tim Düsterhus > > [1] https://wiki.php.net/rfc/asymmetric-visibility#abbreviated_form
Does anyone else have feelings on this point? IMO, the shorthand makes a lot of sense when used with readonly to avoid lines getting just annoyingly long, but without it I can see the argument for not allowing it; it's about a wash in terms of length with readonly today. I'm comfortable going with the consensus on this one for now. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
