Re: [RFC] Asymmetric Visibility, with readonly

> Le 11 déc. 2022 à 20:18, Larry Garfield <larry@garfieldtech.com> a écrit : > > 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 Hi, As of today, the following declarations are rejected as syntax errors: ``php class C { $a; int $b; } ``` while the following declarations are accepted with implicit public visibility: ``php class C { static $c; readonly int $d; } ``` It would be reasonable to propose to allow to consistently omit the public keyword. But allowing to omit it in some cases (including the most controversial one: protected(set)) and not in other cases...? Because of this inconsistency, people are incited to always write explicitly public anyway. —Claude