Ali Saleem

Its a nice concept but the proposed implementation will make defining visibility very complicated. Right now there are 3 visibility options, and its easy to understand what you can and cannot do when working with inheritance. Trying to understand the visibility hierarchy with this new RFC will take some time. https://wiki.php.net/rfc/asymmetric-visibility-v2#inheritance

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.

JavaScript has this, and I've never found the lack of parentheses confusing there. If anything, I think the currently-required wrapper parentheses in PHP add cognitive load when parsing out a statement.

Every time I find myself typing new MyClass() and than returning back and adding those parentheses. It would be good to reduce this friction and make PHP coding flow smoother.

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.

Moving to C# is not a good way IMHO. We will end with classes where properties are heavily mixed with the logic before actually we see class methods.

While I'm not against the concept in general, this implementation is not well-done. The $value variables comes from nowhere and makes it confusing - it looks like an undefined variable and a quick glance at it, was the first thing I thought - where is $value coming from? Why not just use $name within that block? Same with $field? Why not just return the value that is going to be set? This is one of the more confusing RFCs I've seen and does not follow the PHP-code style, makes things confusing for both new and experienced coders. In it's current format, I can't approve with good conscience.

Still hard to read. No extra benefits.

The only clean solution is to use scalar types (string, int, float, boolean) and arrays like objects:

$result = "Hello World"->htmlentities()->split()->map(strtoupper(...))->filter(fn($v) => $v != 'O');

Chain, clean oop, readable, IDE hint, no value parameter, no prefixes and an opportunity to correct the functions inconsistency. It could works beside functions: strtoupper($name) and $name->toUpper().

At least once a week, I throw away an array_map because it ended up looking too bloated and go with a classic foreach instead. Short Closures 2.0 without the use(...) block would've solved this problem, just 2 votes...