Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129642
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 17 Dec 2025 13:48:15 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <bba7305f-de74-4913-88ec-2638ed25e52a@app.fastmail.com>
In-Reply-To: <dbf4a553b5de5188d4bb33befe194f8c@bastelstu.be>
References: <e906b61e-b951-4eb4-aa0f-700e76dae6a9@app.fastmail.com>
 <09b0365c-9708-4c38-8004-5b1ca693ad8c@app.fastmail.com>
 <dbf4a553b5de5188d4bb33befe194f8c@bastelstu.be>
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 Wed, Dec 17, 2025, at 12:02 PM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2025-12-17 16:26, schrieb Larry Garfield:
>> * We have decided on an approach for magic methods.  The updated RFC=20
>> text explains it in more detail, but in short, "if __isset(), then us=
e=20
>> that to determine readable.  Otherwise, __get() implies readable. =20
>> __set() implies writeable."  That should handle the use cases Nicolas=20
>> was interested in.
>
> That works for me. I didn't feel particularly strongly either way.
>
>> We consider the RFC feature complete at this point.  Baring any furth=
er=20
>> substantive discussion, expect a vote in January after the blackout=20
>> period ends.
>
> I don't have further comments about the semantics themselves, but have=20
> one further clarification question:
>
>>  The property has not been unset(). If it has, follow the same __isse=
t=20
>> check as above
>
> Should this read =E2=80=9Cthe same __get check=E2=80=9D instead?

Hm, yes, you are correct.  Updated.

> And one note with regard to process: Don't forget to add a link to the=20
> discussion (https://news-web.php.net/php.internals/129101) to the RFC.

Added.

Oh, and one other note: It turns out that in English, both "writeable" a=
nd "writable" are nominally valid.  The latter seems more common (and my=
 spellchecker only recognizing the latter), so we've standardized on the=
 non-E version throughout the RFC.  (The code already was.)

--Larry Garfield