Zebulan

For situations where you want to have a property be easily readable, but only modifiable in certain ways (e.g. a last-modified-date that should never be altered on its own, but which should be modified whenever an update/save method is run), this is quite useful.

The syntax is certainly not the prettiest, but the arguments in the RFC against using the alternative property-hook-entwined syntax are solid.

This feels a lot nicer than the __get/__set weirdness I currently have to deal with. The ability to define properties as part of an interface contract is something that would have been nice to have in some projects I've previously worked on.

This proposal reduces boilerplate, simplifies developer API contracts, reduces the need for refactors when revising existing code, and aids static analysis tools. The benefits definitely outweigh the cost of the additional syntax to learn and the oddities of said syntax (namely $field), if you ask me.

I had some issues with the syntax in earlier versions of the RFC (namely the number and implementation of shorthand syntax), but most of those have since been addressed, and the only notable one left ($field) is acceptable given the lack of better alternatives.

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.