Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120224
MIME-Version: 1.0
References: <641b1ca0-d33f-4f38-ae64-81b4abce24da@app.fastmail.com> <57aed5a4-f5e5-4a47-bf7a-69249f1d0ef1@app.fastmail.com>
In-Reply-To: <57aed5a4-f5e5-4a47-bf7a-69249f1d0ef1@app.fastmail.com>
Date: Wed, 10 May 2023 13:35:24 +0200
Message-ID: <CAPzBOBOq9VDu9Sjxno8-55aGXOTW+UDGsAZC6VxMdqB0RNEKCw@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] Property hooks, nee accessors
From: landers.robert@gmail.com (Robert Landers)

> Regarding $field vs. $this->propName, there's a few reasons we went that =
route.
>
> 1. It's shorter and less typing for what will be a common pattern.
> 2. That makes it consistent between hook implementations.  In working on =
examples, I found many cases where I was adding basically the same line to =
multiple hooks on the same class.  Making the code easier to copy-paste see=
ms like a win.
> 3. It also will be helpful if hook packages are added in the future, as t=
hey'll need a more "generic" way to access the backing property.  (See Futu=
re Scope.)  Eg, "$field =3D someLogic($value)" applied to a dozen different=
 properties; it wouldn't work if it was "$this->specificProperty =3D someLo=
gic($value)".
> 4. We're used to our eyes glossing over "$this->propName", as it's so com=
mon.  Having a separate name to mentally scan for to determine if a propert=
y is virtual or not seems like it will be helpful in practice.
> 5. There's precedent for it: Kotlin has almost the same functionality as =
we describe here, and uses a `field` variable in the exact same way.
>
> So it's mainly an ergonomics argument rather than a technical one.  "Comp=
ile time macro" means it translates to the same AST as if you'd used $this-=
>propName.  There's precedent for that.  Constructor Property Promotion wor=
ks basically the same way.

With using a common name for say, $value, open the door for a library
of common hook implementations (eventually)?

Maybe something like:

class User {
  // snip
  public string $fullName { get =3D> FancyLibrary\fullName(...) }
  // snip
}

I could imagine something like this would be a huge boon to PHP if it
automatically bound the closure.