Re: [RFC] Asymmetric Visibility, with readonly

>> >> 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. > > I think that Option 1 is the most reasonable. The meaning of public > public(set) and protected protected(set) is > straightforward; from a user point-of-view, disallowing them seems more like “it is useless” > than “it is confusing”. Unless there are good technical reason to restrict it, we can just leave > to linting tools the care of reporting it. > > —Claude > To clarify my position: * The set visibility must be either more restrictive or of the same restriction level than the get visibility. * When the set visibility is absent, it is inferred as following: * If readonly is present, the set visibility is private (as of today); * otherwise, the set visibility is the same as the get visibility (again, as of today). * We don’t judge whether it is reasonable to write protected protected(set) string $foo; when you could just write protected string $foo for the same effect. Similarly, we don’t judge whether it is reasonable to write public function() when you could just write function() for the same effect. We leave it to coding styles and linters to decide whether the short form or the long form is preferred. —Claude