Serhii Cho

Sorry, I don't see any use cases for that

I like the feature but don't like the syntax. something like this is better:

private writable $var;
private readable $var;

Way to confuse new developers! Let's learn them to write private private(set) readonly string $foo; so they want to stop developing and consider starting careers in other fields...

As with a lot of new exceptions to the standard, where do you draw the border in introducing new stuff? Do you also create super custom Exception classes like BookWithTheSameTitleAlreadyExistsException?

What does introducing 'asymmetric visibility' really solve? Writing a bit of boilerplate? Should we then also make an rfc to replace try-catch in a function with something stupid as a fallback in case something throws Exception/Error/etc. or something?

Programming languages should focus on readability for developers. Computers can handle complexity without a sweat, but we as people have limited brain power. Personally, I like to keep my code simple. It should require as little brain capacity as possible to read through my code. That way, we can focus on the general flow and possible bugs.

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.

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.