Serhii Cho

Pretty good addition for the language that will allow to remove lots of boiler plate code

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.

I like the idea behind this RFC, maybe the syntax is not my favourite, but it's ok.

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.

I honestly don't really care about that small sugar, but I lean more towards yes than no, so ship it

makes for cleaner code by removing those useless parentheses

Cleaner code

this allows for cleaner code. less verbose.

Looks like a good idea. first, I thought it will be too complicated for PHP to have this kind of syntax, but I've changed my mind, I think it will be amazing to have it in the language

Since I'm working also with Kotlin I desperatly crave for a feature like this. At least if it is as powerful as in Kotlin where I could e.g. change the setter to be protected or private while the getter can be public

Love it. like in swift. If property observers could be added this would be awesome!

Provides a nice code structure keeping together: declaration, getter and guarded setter

I'm against a multi-inheritance in OOP. I don't think this RFC is necessary for the language. The current OOP system in PHP is already well developed.

I don't usually like syntactic sugar added to the PHP, but this RFC is useful. I totally see use cases for this in my projects because I use short closures all the time.

Such an awful RFC and people are voting for it 😱, weird. I agree with Rasmus Lerdorf, Nikita Popov and Sebastian Bergmann, this PR should NOT go into the language.

I think we should focus more on improving the performance and fixing things that people don't like in PHP rather than implementing new features.

We already have a solid language that does so many things for us, everything else is provided by frameworks. I understand why people want to see features like this one, but I would prefer to focus on the performance and cleaning up the codebase of PHP source code.

this syntax is unclear, and functions who gets multiple arguments will not be properly supported.

I see no immediate benefit of the proposed solution over the userland implementations. The RFC mentions a shopping cart example, but I don't think that's cleaner than using league/pipeline or Laravel's pipeline.

It's a bit messy for the simpler examples as well.

It's almost as messy as putting all the functions into each other.

Makes code more clean because it is shorter and the use keyword is not needed anymore.

Since we have already autocaptures for one liners there should be also option for multiple liners.

Interfaces are contracts. No implementations should be allowed.

The use statements are usually what is keeping me from using the short closures, so having this resolved would make life a lot easier in those cases and the code cleaner

I don't think we need to add business logic to interfaces. Interfaces are contracts, that's the whole beauty of interfaces (that, and the fact that they encourage composition over inheritance, which imo leads to code that is easier to maintain). Having default methods would pollute that premise.

We can already do this with abstract classes. I believe Interfaces should be contracts that leave the implementations up to the implementing classes.