Mart-Jan

Way to confuse new developers! Let's learn them to write private private(set) readonly string $foo; so they want to stop developing and consider starting careers in other fields...

As with a lot of new exceptions to the standard, where do you draw the border in introducing new stuff? Do you also create super custom Exception classes like BookWithTheSameTitleAlreadyExistsException?

What does introducing 'asymmetric visibility' really solve? Writing a bit of boilerplate? Should we then also make an rfc to replace try-catch in a function with something stupid as a fallback in case something throws Exception/Error/etc. or something?

Programming languages should focus on readability for developers. Computers can handle complexity without a sweat, but we as people have limited brain power. Personally, I like to keep my code simple. It should require as little brain capacity as possible to read through my code. That way, we can focus on the general flow and possible bugs.

This really makes the language complex.
The part with the interactions with the readonly keyword is really hard to make sense of.

I understand the subtle differences, don't get me wrong, it's just that I cannot understand them by just looking at the property definitions quickly. Imagine having to quickly make sense of a class with a dozen of properties like that. It's just nightmarish. I wouldn't accept a merge request that messy in my codebase.

I feel like if you need that much fine-grain control this is when having explicit getters/setters make sense.

Add property hooks on top of that and you have an explosion of complexity where you don't want: your domain logic is complex enough on it's own, you don't want to have properties become a maze.

It certainly is a fancy feature, but it takes too much a toll on the cognitive load.

Right now visibility is straight-forward. In a glance I can map in my head the possible operations on a property when I see its visibility. Adding this to the language will mean there will be moments that I'll have to stop and work out exactly what it means I can do with a property.

Also, property hooks already solve these use cases: defining a virtual property hook with only a getter will prevent you from setting the property, and vice versa.

This is one of the things that I come across so often, numerous times within every project. It makes sense for PHP to get rid of boilerplate wherever it can. If the compiler can figure out the details, then I prefer not having to micro-manage every bracket.