Willian Damasceno

This is good, many times I've written code like that, and it just did not worked.

It is confusing for me, I think readonly is enough for most use cases, this will be complex and probably will not cover some edge cases, so new features will be placed on top? It should not be in the language.

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

this allows for cleaner code. less verbose.

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.

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;
    }
}

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.