Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129552
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 04 Dec 2025 10:59:52 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <b95d10f5-df03-483a-b80f-a0b5a478c2bc@app.fastmail.com>
In-Reply-To: 
 <CAOWwgpk8+18HzhsK235h35b2a2unKH=k+q9ch+Y+j=A+yWegcQ@mail.gmail.com>
References: <e906b61e-b951-4eb4-aa0f-700e76dae6a9@app.fastmail.com>
 <CAOWwgp=L=YaZDdLmFr+paOVEotU1Lt6S4vAuU+HFTNAo0S0hSQ@mail.gmail.com>
 <d221df4a-cb0c-4729-a7b3-156b0db52ff6@app.fastmail.com>
 <CAOWwgpk8+18HzhsK235h35b2a2unKH=k+q9ch+Y+j=A+yWegcQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] isReadable/isWriteable property reflection
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Dec 4, 2025, at 10:47 AM, Nicolas Grekas wrote:
> Le jeu. 4 d=C3=A9c. 2025 =C3=A0 17:39, Larry Garfield <larry@garfieldt=
ech.com> a =C3=A9crit :
>> On Thu, Dec 4, 2025, at 8:05 AM, Nicolas Grekas wrote:
>> > Le jeu. 6 nov. 2025 =C3=A0 00:28, Larry Garfield <larry@garfieldtec=
h.com> a =C3=A9crit :
>> >> In other news, Ilija and I said a year ago that we'd take a swing =
at adding isReadable/isWriteable methods to ReflectionProperty.  Took a =
while, but here we are.  A strangely small RFC from us:
>> >>=20
>> >> https://wiki.php.net/rfc/isreadable-iswriteable
>> >>=20
>> >
>> >
>> > Thanks for this.
>> > I also think the auto-scope is [NOT] a good idea. You state that 90=
% of use=20
>> > cases will need this but my experience doesn't back this claim. The=20
>> > only cases where I had to check for read/writeable were out of the=20
>> > local scope, so I'd say 100% of my experience goes against that 90%=20
>> > number ;) Joke aside, it'd be just fine to let ppl be explicit. Tha=
t's=20
>> > better than "oops I forgot to give the correct scope" bugs.
>> >
>> > About magic methods, one unsets a property only to have __get/__set=20
>> > called. Existing code works with this assumption. This means we hav=
e to=20
>> > return true IMHO. Magic methods are just generic hooks also. Which=20
>> > means they should behave the same.
>> >
>> > Nicolas
>>=20
>> Well, the only people who seem to have an opinion don't like "static"=
, so we've removed it.  RFC updated.
>>=20
>> As for __get/__set, that's so far one vote for ignore (Tim), and one =
for always-true (Nicolas).  Not a consensus. :-)
>>=20
>> Nicolas, can you clarify with an example if/how ignore would break th=
ings? =20
>>=20
>> I think once we settle that question and the cooldown passes we're re=
ady for a vote, though at this point that means January.
>>=20
>
> I can try to build a synthetic example but the gist is:
> A class that starts with only properties and no __get() should be able=20
> to move to a __get()-based hooking in a later version without breaking=20
> code that uses isReadable().
> That on its own should be enough to settle the desired behavior :)

So you want to be able to transition from:

class Foo
{
  public private(set) string $name;
}

To

class Foo
{
  private array $vals =3D [];

  public function __get(string $name)
  {
    return $this->vals[$name] ?? throw new Exception();
  }
}

Is that right?  Because both approaches would result in changes in some =
situations there.

If __get is ignored and the value is set, then a global isReadable check=
 will go from true to false in that transition.

If __get always returns true and the value is still uninitialized, a glo=
bal isReadable check will go from false to true in that transition.

Either way, that's not a fully safe transition to make.

--Larry Garfield