Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122653
Feedback-ID: id5114917:Fastmail
Date: Sat, 16 Mar 2024 08:32:39 +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: <e18863f1-9cc9-400b-b6b4-d1be62fa4d0f@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> <C517590C-77D1-462C-92E9-D2851345BE67@rwec.co.uk> <e18863f1-9cc9-400b-b6b4-d1be62fa4d0f@app.fastmail.com>
Message-ID: <46609F15-DD40-4BD2-A78A-16021C3447C8@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 16 March 2024 00:19:57 GMT, Larry Garfield <larry@garfieldtech=2Ecom> w=
rote:

>Well, reading/writing from within a set/get hook is an obvious use case t=
o support=2E  We cannot do cached properties easily otherwise:
>
>public string $expensive {
>  get =3D> $this->expensive ??=3D $this->compute();
>  set {=20
>    if (strlen($value) < 50) throw new Exception();
>    $this->expensive =3D $value;
>  }
>}


To play devil's advocate, in an implementation with only virtual propertie=
s, this is still perfectly possible, just one declaration longer:

private string $_expensive;
public string $expensive {
  get =3D> $this->_expensive ??=3D $this->compute();
  set {=20
    if (strlen($value) < 50) throw new Exception();
    $this->_expensive =3D $value;
  }
}

Note that in this version there is an unambiguous way to refer to the raw =
value from anywhere else in the class, if you wanted a clearAll() method fo=
r instance=2E

I can't stress enough that this is where a lot of my thinking comes from: =
that backed properties are really the special case, not the default=2E Anyt=
hing you can do with a backed property you can do with a virtual one, but t=
he opposite will never be true=2E


The minimum version of backed properties is basically just sugar for that =
- the property is still essentially virtual, but the language declares the =
backing property for you, leading to:

public string $expensive {
  get =3D> $field ??=3D $this->compute();
  set {=20
    if (strlen($value) < 50) throw new Exception();
    $field =3D $value;
  }
}

I realise now that this isn't actually how the current implementation work=
s, but again I wanted to illustrate where I'm coming from: that backed prop=
erties are just a convenience, not a different type of property with its ow=
n rules=2E



> Being the same also makes the language more predictable, which is also a=
 design goal for this RFC=2E  (Hence why "this is the same logic as methods=
/__get/other very similar thing" is mentioned several times in the RFC=2E  =
Consistency in expectations is generally a good thing=2E)

I can only speak for myself, but my expectations were based on:

a) How __get and __set are used in practice=2E That generally involves rea=
ding and writing a private property, of either the same or different name f=
rom the public one; and that private property is visible everywhere equally=
, no special handling based on the call stack=2E

b) What happens if you accidentally cause infinite recursion in a normal f=
unction or method, which is that the language eventually hits a stack depth=
 limit and throws an error=2E

So the assertion that the proposal was consistent with expectations surpri=
sed me=2E It feels to me like something that will seem surprising to people=
 when they first encounter it, but useful once they understand the implicat=
ions=2E


Regards,
Rowan Tommins
[IMSoP]