Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120306
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> <CAG4FTXw1ugSqQVxq1H1W=2j+cFy7Q3yxQwXVizsPTJtSieznPg@mail.gmail.com>
 <4947b8d1-1c1d-445d-ba9b-a21f21772548@app.fastmail.com>
In-Reply-To: <4947b8d1-1c1d-445d-ba9b-a21f21772548@app.fastmail.com>
Date: Tue, 16 May 2023 08:18:08 +0700
Message-ID: <CAG4FTXy6gXha5RN0DSUvYOO2ZcJ4sX79ObpqLEWD3z1MN+9FgA@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)

> Secondary votes are generally discouraged.  I can see the argument for wa=
nting a short-short version of set, given how common the validation use cas=
e is, but =3D> is almost universally the "evaluates to" symbol, so using th=
at for a set operation rather than get just feels weirdly inconsistent.  If=
 there were a set-only shorthand, it should be something else.
>
> That said, the ideal for validation would probably be guard clauses, like=
 this, but that would be a completely different RFC for another time.
> ```
> function foo(string $name where strlen($name) < 10) { ... }
>
> class Foo {
>   public function __construct(
>     public string $name where strlen($name) < 10;
>   ) {}
> }
> ```
```guard``` seems a subset feature of ```hook```, although you want to
expand its use case in parameter. Property and parameter are variable.
If ```guard``` can be implemented in both case as you write above,
theoretically  ```hook``` can be either. I will choose ```hook```
rather than ```guard``` to anticipate future expansion. Isn't it
better to choose one broad concept than many?

I found a contradiction here. Previously you said that:
> ... the problem with omitting the {} is that it creates yet another synta=
x variant. That makes it harder for the parser, for static analyzers, for u=
ser-space parsing tools like php-parser, etc. That's more work for everyone=
 for fairly little gain.

And here, you introduce a syntax variant. Is it really significant if
we introduce a new ```where``` keyword ```compared to the already used
```get``` keyword? I will clarify here in case there is
misunderstanding:
* If we have more than one hook per property, then the syntax will be
the same as proposed by RFC.
* If we have only one hook per property, than the syntax are:
```
public function __construct(
  public string $prop1 get =3D> strtoupper($this->_prop1),
){}

public function __construct(
  public string $prop2 set =3D> $field =3D strtolower($value),
){}

public function __construct(
  public string $prop3 get {
    $temp =3D strtoupper($this->_prop1);
    return substr($temp, 0, 10) . '...';
  },
){}

public function __construct(
  public string $prop4 set {
    $temp =3D strtolower($value);
    $field =3D substr($temp, 0, 10);
  },
){}
```
Note: Please ignore any error. The ending comma is actually part of
the parameter list, not a hook. So it becomes optional if the param is
only one or it is the last param.

All the examples are constructor property promotion, because that is
my only concern. Because the space is limited, the more consistent the
code, the better. If I have to write hooks outside CPP, I don't mind
using the other syntax. There's plenty of room to fill, and
consistency is tolerable.

Should we postpone the implementation of the shortest version?
Hopefully we have enough time to decide which one will be implemented
next.

>
> ... Ilija also noted to me off-list that you could also have a set hook t=
hat throws an exception rather than just being null, which would also work =
to prevent writes.

Such a coincidence. I was going to revise my code:
```
// cache once and freeze,
// and without additional hidden property
// in case asymmetric visibility in not implemented yet
public string $prop1 {
  get =3D> $field ??=3D $this->heavyTask($this->propx, $prop->y);
  set =3D> throw new Exception("prop1 is read only");
}
```

> I think an unset hook is a fine addition in the future.  The way the code=
 is implemented it should be straightforward to add.  However, it feels lik=
e scope creep to include it right now, especially when there are workaround=
s available.  If there's a clear consensus from voters to include it, thoug=
h, we can consider that.  (Meaning, anyone that would favor including an un=
set hook now, speak up or we'll assume it's better to stick with just get/s=
et for now.)

+1 for including ```unset``` as part of this RFC.