On Fri, Aug 5, 2022 at 10:25 PM Larry Garfield <la...@garfieldtech.com> wrote: > > On Fri, Aug 5, 2022, at 1:08 PM, Matthew Weier O'Phinney wrote: > > On Fri, Aug 5, 2022, 12:09 PM Larry Garfield <la...@garfieldtech.com> 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 >
Hello, First of all, this is exciting! Looking at the behavior for references, can we explore the edges a bit? (I didn't see any tests that cover this functionality in the PR) 1. Passing a function a reference to a private-set property is allowed, such as to sort(). 2. Returning a reference to a private-set property is allowed and usable. 3. Trying to get a NEW reference to a private-set property outside of the defined scope is not allowed. So if I'm understanding correctly, references to private-set properties can be used outside of the defined scope but they can't be created outside of the defined scope? If so, should we fire off a Notice when references are modified outside of the defined scope? I can see that being annoying in certain contexts, such as sorting an array, so maybe not? FWIW, this behavior doesn't apply to readonly properties because attempting to pass a reference to the property fails. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
