Geoffrey van Wyk

With this feature, one can conveniently set a property directly, but still have validation on it behind the scenes. This is more convenient than using __set.

This makes things easier.

It is awesome.

Let us rather remove the writeonce behavior from readonly and add a separate writeonce keyword.

The private(set) syntax is also ugly.

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.

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.

I think this would be a great improvement.

I prefer this:

$result = "Hello World"
    |> htmlentities(...)
    |> str_split(...)
    |> fn($x) => array_map(strtoupper(...), $x)
    |> fn($x) => array_filter($x, fn($v) => $v != 'O');

instead of this:

$result = "Hello World"
    |> 'htmlentities'
    |> 'str_split'
    |> fn($x) => array_map('strtoupper', $x)
    |> fn($x) => array_filter($x, fn($v) => $v != 'O');

With First-class callable syntax available since 8.1, it would now be possible to write it as below, which is much better then string names of functions:

$result = "Hello World"
    |> htmlentities(...)
    |> str_split(...)
    |> fn($x) => array_map(strtoupper(...), $x)
    |> fn($x) => array_filter($x, fn($v) => $v != 'O');

For me, the most important argument is that the pipeline pattern is a tried and tested pattern, that this RFC builds upon. A couple of examples:

• league/pipeline
• laravel's pipeline

This RFC adds syntax to make using these kinds of pattern much more convenient.

On top of that, there's the argument that multiple modern languages support a pipe operator:

• Hack
• Haskall
• Ruby
• Elixir
• And more

Finally, I've had numerous occasions where a pipe operator would simplify my own code — I have more than a handful real life cases where this would be useful.