Asymmetric Visibility v2

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.

I like the functionality this RFC provides and think this should come to PHP. But i don't like introducing a new keyword and syntax for this because it also increases the cognitive load. I would like the Property Hook approach that is discussed in the RFC more or using Attributes like the #[\SensitiveParameter]:

class Foo
{
	#[PrivateSet]
	public string $bar = 'baz';
}

or

class Foo
{
	#[Set(Private)]
	public string $bar = 'baz';
}

or some other Attribute. We should try to use existing syntax first.

Its a nice concept but the proposed implementation will make defining visibility very complicated. Right now there are 3 visibility options, and its easy to understand what you can and cannot do when working with inheritance. Trying to understand the visibility hierarchy with this new RFC will take some time. https://wiki.php.net/rfc/asymmetric-visibility-v2#inheritance

Asymmetric visibility allows for properties that are publicly readable but privately writable. This means that while the value can be accessed from anywhere, it can only be changed in controlled, intentional ways. By making a property writable only within a private scope, you can ensure that only specific methods or functions can modify it. This reduces the risk of unintended side effects from external code, which can potentially corrupt the state of the object.

It adds complexity, it can be confusing, but i think it's an important step forward for php to implement such feature.

For the readonly vs. asymmetric visibility discussion: you can mix them up since they aim a different goals (write-once vs writing from).

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.

Readonly properties only allow you to set a property in the constructor. Some times, you want to make your property public while only ensuring that it's only changeable within the confines of your class. This feature will make that possible

Don't like the syntax

For those saying "No," ask yourselves if it's the feature itself you're opposed to, or the level of knowledge you will need in order to use it properly. Then ask whether you'll need this language feature. If you don't need it, don't use it. If you don't want to learn it, don't. But I feel it's good for the language to regain traction in the development space if it's capable of the same patterns as others.

Aside from competition, I like this feature for the following:

• Eliminate getter/setter methods that are nothing but cruft on top of direct read/write access of the property. Get back to writing functions that do things, not just carry the property in and out of the object.
• Control object state more flexibly instead of micromanaging properties between parent/child inheritance
• Reduce the boilerplate of constructors having to declare parameters instead of promoted properties, then pass the argument up to the parent's promoted property.

The syntax in the RFC adds complexity, yes. But we've all gotten used to other degrees of complexity as the language has grown and matured. Remember when visibility wasn't even a thing yet? Remember when constructing an object required a method matching the class's name? Growing pains hurt sometimes, but that doesn't mean they're not worthwhile.

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

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.