Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118361
MIME-Version: 1.0
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
 <CAJp_myVOPbe9B3YPNtNC79Avj1BN4d5eSqXKomiDVOutd00w9g@mail.gmail.com> <0923bd88-8e62-4386-bf6b-4ef9456780b4@www.fastmail.com>
In-Reply-To: <0923bd88-8e62-4386-bf6b-4ef9456780b4@www.fastmail.com>
Date: Sat, 6 Aug 2022 09:30:05 +0200
Message-ID: <CAPzBOBNVD4L=5b5q1pP2-_QCGLiyhkQbvYHzn10-X4RT4daufQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: landers.robert@gmail.com (Robert Landers)

On Fri, Aug 5, 2022 at 10:25 PM Larry Garfield <larry@garfieldtech.com> wro=
te:
>
> On Fri, Aug 5, 2022, at 1:08 PM, Matthew Weier O'Phinney wrote:
> > On Fri, Aug 5, 2022, 12:09 PM Larry Garfield <larry@garfieldtech.com> w=
rote:
> >
> >> 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 wi=
ll
> > be cumbersome; you'd need to check both to determine if you'd need to m=
ake
> > the reflection property accessible before changing the value. An
> > isPublicSet() would alleviate that, or potentially a getSetFlags() meth=
od
> > 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() metho=
ds on ReflectionProperty, so this is consistent.  Also, there's getModifier=
s() which returns a bitmask; these new flags would be included there.  All =
these methods all do is check what is syntactically present, both the curre=
nt ones and proposed ones.
>
> There's definitely room in the Reflection API for a "couldItBeModifiedFro=
mScope($scope)" type method (and similar) that aggregates together symmetri=
c visibility, readonly, asymmetric visibility, etc. into nice booleans.  Ho=
wever, 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. Thi=
s
> > 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 a=
ppropriate here to use an attribute.
>
> * It would mean get-visibility is a keyword and set-visibility is an attr=
ibute.  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 attribut=
es that's OK, but in this case it would be a potential bug source.  Specifi=
cally, it would mean `#[PrivateSet] \n public string $value` would be publi=
cly 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.