> (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
> 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?
> Removing the {} entirely from all forms makes it harder to denote where the
> list of hooks begins and ends. They would probably have to be
> comma-separated, like this:
>
> public string $foo
> get { return $this->bar; },
> set { $this->bar = $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, 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);
}
```
> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
