Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122649
Feedback-ID: id5114917:Fastmail
Date: Fri, 15 Mar 2024 23:25:37 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
User-Agent: K-9 Mail for Android
In-Reply-To: <154481e0-5f62-4026-994a-28a644d71527@app.fastmail.com>
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com> <a715dacb-9bac-4bea-a2bb-c623737fd81e@app.fastmail.com> <c057b162-e2fe-4ade-b27f-e09815743748@rwec.co.uk> <7eada0fd-39c5-4a89-8c74-80c671801a2d@app.fastmail.com> <1698692e-8eb1-4bfc-a743-375696cd8f1c@rwec.co.uk> <154481e0-5f62-4026-994a-28a644d71527@app.fastmail.com>
Message-ID: <C517590C-77D1-462C-92E9-D2851345BE67@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 15 March 2024 17:11:29 GMT, Larry Garfield <larry@garfieldtech=2Ecom> w=
rote:
>On Wed, Mar 13, 2024, at 10:26 PM, Rowan Tommins [IMSoP] wrote:
>> I think it would be more helpful to justify this design on its own=20
>> merits, particularly because it's a significant difference from other=
=20
>> languages (which either don't have a "real property" behind the hooks,=
=20
>> or in Kotlin's case allow access to it only *directly* inside the hook=
=20
>> definitions, via the "field" keyword)=2E
>
>I'm not sure I follow=2E  The behavior we have currently is very close to=
 how Kotlin works, from a user perspective=2E


Unless I'm misunderstanding something, the backing field in Kotlin is acce=
ssible only inside the hooks, nowhere else=2E I don't know what would happe=
n if a hook caused a recursive call to itself, but there's no mention in th=
e docs of it bypassing the hooks, only this:

> This backing field can be referenced in the accessors using the `field` =
identifier

and

> The `field` identifier can only be used in the accessors of the property=
=2E

And then a section explaining that more complex hooks should use a separat=
e backing property - which is the only option in C#, and roughly what peopl=
e would do in PHP today with __get and __set=2E

Kotlin does have a special syntax for "delegating" hooks, but looking at t=
he examples, they do not use the backing field at all, they have to provide=
 their own storage=2E



>I've lost track of which specific issue you have an issue with or would w=
ant changed=2E  The guards to prevent an infinite loop are necessary, for t=
he same reasons as they are necessary for __get/__set=2E

I understand that *something* needs to happen if a recursive call happens,=
 but it could just be an error, like any other unbounded recursion=2E=20

I can also understand the temptation to make it something more useful than=
 an error, and provide a way to access the "backing field" / "raw value" fr=
om outside the hook=2E But it does lead to something quite surprising: the =
same line of code does different things depending on how it is called=2E

I doubt many people have ever discovered that __get and __set work that wa=
y, since as far as I can see it's only possible to use deliberately if you'=
re dynamically adding and unsetting properties inside your class=2E

So, I don't necessarily think hooks working that way is the wrong decision=
, I just think it's a decision we should make consciously, not one that's o=
bvious=2E
=20
=20
Regards,
Rowan Tommins
[IMSoP]