Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120304
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-415-gf2b17fe6c3-fm-20230503.001-gf2b17fe6
Mime-Version: 1.0
Message-ID: <4947b8d1-1c1d-445d-ba9b-a21f21772548@app.fastmail.com>
In-Reply-To: 
 <CAG4FTXw1ugSqQVxq1H1W=2j+cFy7Q3yxQwXVizsPTJtSieznPg@mail.gmail.com>
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>
Date: Mon, 15 May 2023 21:06:25 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Property hooks, nee accessors
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, May 15, 2023, at 8:12 PM, Hendra Gunawan wrote:

>> For the second, the problem with omitting the {} is that it creates yet another syntax variant.  That makes it harder for the parser, for static analyzers, for user-space parsing tools like php-parser, etc.  That's more work 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?

Secondary votes are generally discouraged.  I can see the argument for wanting a short-short version of set, given how common the validation use case is, but => is almost universally the "evaluates to" symbol, so using that 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;
  ) {}
}

>> What we really would need here is asymmetric visibility.  No set hook, but make the property private(set) so that trying to write to it gives an error, 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 => $field ??= $this->heavyTask($this->propx, $prop->y);
> }
> ```

If you don't want cache clearing, yes.  Ilija also noted to me off-list that you could also have a set hook that throws an exception rather than just being null, which would also work to prevent writes.

For clearing that cached value, I think an unset hook is probably the best way, with either approach.

>>  For cache clearing, the best way to do that is probably with an unset hook.  That's been omitted from the RFC for now for simplicity, but that sounds 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.

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 like scope creep to include it right now, especially when there are workarounds available.  If there's a clear consensus from voters to include it, though, we can consider that.  (Meaning, anyone that would favor including an unset hook now, speak up or we'll assume it's better to stick with just get/set for now.)

--Larry Garfield