Brent

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'm conflicted about this RFC. I definitely have use cases for "publicly readable and privately writable" properties. Especially since we still don't have clone with. I'm a afraid of the overlap between asymmetric visibility with readonly properties. By introducing asymmetric visibility, we make readonly properties essentially useless (asymmetric visibility can do the same, and more). I wonder how the community will deal with such a change: readonly properties were introduced in PHP 8.1, what happens if they become obsolete only a couple of versions later?

Despite my worry, I like this proposal on its own, and it would actually be useful to me in many cases. In the end, I'm inclined more towards voting yes than no.

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.

Often, I add static methods to some classes in order to improve readability when I instantiate a new class; the ability of chaining methods directly to the constructor, without the unnecessary parenthesis boilerplate, would remove the need for that.

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.

Nice addition, but I would change syntax:

class User 
{
    public string $name {
        set($value) {
            if (strlen($value) === 0) {
                throw new ValueError("Name must be non-empty");
            }
            return $value;
        }
    }
 
    public function __construct(string $name) {
        $this->name = $name;
    }
}

Thanks to readonly properties, I started relying more and more on properties alone. However, I actually often find the need for more fine-grained control over input and output, but adding methods feels so heavy-weight. Property hooks feels like the perfect solution for some of my use cases.

In combination with Asymmetric visibility this will allow to replace all getters and setters with trivial properties and occasional hooks.

This is good to have.

Properties are useful for exchanging (reading and writing) single values. Properties are good for data binding, etc.

With this RFC we can implement:

• Validation
• Trigger events
• Call methods if there is more to do

Update: About the $field I am not sure. Having a separate backing field can have some advantages.

It's like Accessors/Mutators in Laravel but native.

For example:

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

Is 'nicer' since it has better readability and clearer syntax than:

$result = array_filter(
        str_split(
            strtoupper(
                htmlentities("Hello World")
            )
        ),
        fn($v) => $v != '0'
    );

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');

I could have used it multiple times for array transformations. But the RFC still built on really ancient PHP behaviour (mapping functions as strings) and should be redone by fosucing only on modern syntax:

• closures and short closure: |> fn($x) => array_filter($x, fn($v) => $v != 'O')
• first class callable syntax: |> str_split(...)

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.

Technically writing a trait isn't a showstopper, but it adds cognitive load because the developer now must know/remember using this Interface requires adding this Trait. PHP should focus more on development experience!

PHP is evolving. There are new concepts added to many programming languages to ease writing and reading (more important!). PHP should focus more on developer experience (but not for legacy projects that get never upgraded to PHP 8+).

I personally don't need it but I guess it could be useful to people.

We spend a lot more time reading code than writing it. The elegance of short closure combined with the convenience of variable scope usage has already shown to be a game changer on Typescript and there doesn’t seem to be any technical issue with having it on PHP.

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...

Creating traits for default implementation is just a pain. I want syntactic sugar

I wrote down some thoughts on this RFC on my blog. I think it's worth rethinking our current definition of what "an interface" is. Especially since many languages are interface default methods as their way of multi-inheritance.