Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120303
MIME-Version: 1.0
References: <641b1ca0-d33f-4f38-ae64-81b4abce24da@app.fastmail.com>
 <CAG4FTXzt6qnpawSgPftnuXhNz9b1RAPtrOvVwvgY723W6WeLDA@mail.gmail.com> <b501b7ac-0193-4604-a9b2-e03e69ba335c@app.fastmail.com>
In-Reply-To: <b501b7ac-0193-4604-a9b2-e03e69ba335c@app.fastmail.com>
Date: Tue, 16 May 2023 03:12:06 +0700
Message-ID: <CAG4FTXw1ugSqQVxq1H1W=2j+cFy7Q3yxQwXVizsPTJtSieznPg@mail.gmail.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: the.liquid.metal@gmail.com (Hendra Gunawan)

> (Also, when replying, please please remove duplicate names from the to/cc=
 line.  I just got double copies of everything in this thread this morning.=
  I'm on the list, I don't need to be CCed.)

Sorry about that. Not my habit before.

> For the second, the problem with omitting the {} is that it creates yet a=
nother syntax variant.  That makes it harder for the parser, for static ana=
lyzers, for user-space parsing tools like php-parser, etc.  That's more wor=
k for everyone for fairly little gain.

Sad to read that. Making one of them as the shortest shorthand feels
like a picky decision. Some people agree with ```get```. Some people
will argue that ```set``` deserves more than ```get```. Personally, I
choose ```set``` to be the shortest shorthand as it is more relevant
with constructor property promotion and value object. Do we need a 2nd
vote for this one?

> Removing the {} entirely from all forms makes it harder to denote where t=
he list of hooks begins and ends.  They would probably have to be comma-sep=
arated, like this:
>
> public string $foo
>   get { return $this->bar; },
>   set { $this->bar =3D $value; };
>
> Which I'd argue is harder to read anyway, because you have to be careful =
of the very small , and ; marks.  The {} is just easier for humans to parse=
 as well as the machine.

Looks like it's not more simple compared to the other one.

> What we really would need here is asymmetric visibility.  No set hook, bu=
t make the property private(set) so that trying to write to it gives an err=
or, as it should.

So if asymmetric visibility is implemented, will my code be this simple?
```
// cache once and freeze,
// and without additional hidden property
public private(set) string $prop1 {
  get =3D> $field ??=3D $this->heavyTask($this->propx, $prop->y);
}
```

>  For cache clearing, the best way to do that is probably with an unset ho=
ok.  That's been omitted from the RFC for now for simplicity, but that soun=
ds like it would be an argument to introduce it later.

I was going to write about this one. IMO, why do we need to provide
additional hidden properties, when we are able to store the cache
directly into it? Obviously we need a ```unset``` hook.