Re: [RFC] Asymmetric visibility

On Fri, Aug 5, 2022, at 2:27 PM, Michał Marcin Brzuchalski wrote: > Hi Larry, > > pt., 5 sie 2022, 19:09 użytkownik Larry Garfield <larry@garfieldtech.com> > napisał: > >> Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: >> Asymmetric Visibility. >> >> https://wiki.php.net/rfc/asymmetric-visibility >> >> Details are in the RFC, but it's largely a copy of Swift's support for the >> same. >> > > Thanks for taking efforts on new RFC. > > Why not C# style property accessors? It feels more natural for me while > Swift solution IMHO looks weird/odd composed with PHP class definition > syntax. The arguments in favor from the RFC look forcibly (couldn't find > better word). > > Cheers, > Michał Marcin Brzuchalski There's a couple of reasons. Ilija and I have spent quite a bit of time brainstorming through accessors, and there's still a lot to finalize there, and lots of bikeshed potential. It's a non-simple problem space. However, asymmetric visibility is a good stand-alone concept that can work without accessors, and has ample benefits of its own without accessors, and has far less bikeshed potential. (There's minor debates that might be had over syntax, but the behavior is fairly "it is or it isn't".) So the primary reason is that this syntax allows us to have asymmetric visibility without having to think about accessors. We can then, at some point in the future, have a different discussion about accessors and not have to worry about asymmetric visibility in the process. The C# syntax by nature only works if they come together in the same RFC, or at least one RFC is built such that it locks in some decisions for the other RFC. As an example, one thing we've been discussing is if accessors should be inline with the property (a la Swift and C#) or annotated methods (as in Javascript and Python). There's good arguments for both approaches, as well as good arguments against. But those would have *extremely* different implications for how we represent asymmetric visibility. So if we took the C# style for asymmetric visibility, that would realistically lock us into C# style accessors even before we've had the discussion about if we want that or not. That's not good. (Please don't anyone try to debate which accessor approach to take here; the whole point is we want to introduce asymmetric visibility without having that debate yet. We'll be able to have it in the future, I'm sure.. There's other knock-on effects as well that I'm skipping for now as not relevant.) Keeping them separate also makes extending visibility rules in different directions (as noted in the Future Scope section) at some point in the future can also be done without bumping into accessors. Whether or not those directions are useful is a topic for another time, but it again allows us to discuss those (like a "once" operation or a "package" scope, etc.) without worrying about the impact on accessors. Secondarily, the C# style means you have to look both before and after the property itself to know what its visibility rules are. That's increased cognitive load. This way, all of the various "flags" on a property remain in the same place, and presumably 99.999% of developers will put public private(set) right next to each other like that. That makes the visibility readable all from one spot, and if all you're using is that and not accessors in the future, the impact on your existing reading skills is minimized. This one is admittedly a bit more subjective, but readability and cognitive load are certainly considerations to, er, consider. --Larry Garfield