Re: [PHP-DEV] [RFC] Asymmetric visibility
On Fri, Aug 5, 2022, at 1:08 PM, Matthew Weier O'Phinney wrote: > On Fri, Aug 5, 2022, 12:09 PM Larry Garfield wrote: > >> 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. >> > > I have two comments: > > - For reflection purposes, having two separate methods feels like it will > be cumbersome; you'd need to check both to determine if you'd need to make > the reflection property accessible before changing the value. An > isPublicSet() would alleviate that, or potentially a getSetFlags() method > against which you could apply a bit mask. You'd need to add a constant for > public set I both cases. Reflection is a mess, unfortunately. :-( There's already separate isPrivate(), isProtected(), and isPublic() methods on ReflectionProperty, so this is consistent. Also, there's getModifiers() which returns a bitmask; these new flags would be included there. All these methods all do is check what is syntactically present, both the current ones and proposed ones. There's definitely room in the Reflection API for a "couldItBeModifiedFromScope($scope)" type method (and similar) that aggregates together symmetric visibility, readonly, asymmetric visibility, etc. into nice booleans. However, that is notably more work than just adding more syntax flag methods. It would probably be better as its own RFC, though I'd support that. If there's consensus that it has to be done here that could be done, but we'd prefer not as it feels like scope creep. > - The number of items that appear to the left of a property is growing, > making understanding a declaration increasingly difficult, and your > discussion of future scope indicates that this is likely to get worse. I'm > wondering if this sort of behavior could be indicated via attributes > instead? Something like `#[PropertySetBehavior(PROPERTY_SET_PRIVATE)]`. > Attributes have the benefit of being separate from the property > declaration, arguably more readable (one per line), and composable. This > might play into some of the future scope items as well. The list indeed groweth, but there's a couple of reasons it wouldn't be appropriate here to use an attribute. * It would mean get-visibility is a keyword and set-visibility is an attribute. That's weird and inconsistent. * There's a strong sense from many on the list that attributes should not be used for language behavior. Ilija agrees with that position, and I don't care enough to fight it one way or the other. * An attribute would be ignored in older PHP versions. For most attributes that's OK, but in this case it would be a potential bug source. Specifically, it would mean `#[PrivateSet] \n public string $value` would be publicly settable on PHP 8.2, but not publicly settable in 8.3. That means the integrity of the object is compromised on older versions. A keyword would make that a syntax error, which in this case is preferable. > Overall, though, love the design simplicity! Yay! --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Asymmetric visibility
On Fri, 5 Aug 2022, 20:53 Larry Garfield, wrote: > 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 > > > 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. > Feedback: 1. The idea is cool 2. when I opened the RFC and looked at the syntax, I wasnt able to intuitively (self documenting code) figure out what and why was going on. 3. The syntax is heavily implicit as to what each keyword and syntax means, so the general PHP developer would struggle or mis understand what is going on. 4. MWOP's point of there being a lot of keywords and prefixes at class property declaration is not really cluttered (lots going on), is accurate. Perhaps splitting it into an explicit Attribute might yield a better DX? Ilina and Larry, all in all I know this is a WIP and you're looking for early feedback, so this is my feedback, to be considered. Looking forward to reviewing future revisions of this. Thanks for the effort and time you've put in so far <3 > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [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 > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Asymmetric visibility
On Fri, Aug 5, 2022, at 12:39 PM, Thomas Nunninger wrote: > Hi, > Am 05.08.22 um 19:08 schrieb Larry Garfield: >> 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. > > Great to hear that there is a new and simple proposals. > > One note: In the example about references, I assume the class Baz must > extend from Foo. Yep, thanks, that's a typo on my part. Fixed now. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Asymmetric visibility
Hi Larry, pt., 5 sie 2022, 19:09 użytkownik Larry Garfield 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
Re: [PHP-DEV] [RFC] Asymmetric visibility
On Fri, Aug 5, 2022, 12:09 PM Larry Garfield wrote: > 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. > I have two comments: - For reflection purposes, having two separate methods feels like it will be cumbersome; you'd need to check both to determine if you'd need to make the reflection property accessible before changing the value. An isPublicSet() would alleviate that, or potentially a getSetFlags() method against which you could apply a bit mask. You'd need to add a constant for public set I both cases. - The number of items that appear to the left of a property is growing, making understanding a declaration increasingly difficult, and your discussion of future scope indicates that this is likely to get worse. I'm wondering if this sort of behavior could be indicated via attributes instead? Something like `#[PropertySetBehavior(PROPERTY_SET_PRIVATE)]`. Attributes have the benefit of being separate from the property declaration, arguably more readable (one per line), and composable. This might play into some of the future scope items as well. Overall, though, love the design simplicity! > -- > Larry Garfield > la...@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Asymmetric visibility
Hi, Am 05.08.22 um 19:08 schrieb Larry Garfield: 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. Great to hear that there is a new and simple proposals. One note: In the example about references, I assume the class Baz must extend from Foo. Good luck with this proposal Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Asymmetric visibility
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. -- Larry Garfield la...@garfieldtech.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
