Asymmetric visibility gives more fine-grained control over when a property can be read or written to. For example: you can make a property readable from everywhere, but only writable from within the private scope.
class Foo { public private(set) string $bar = 'baz'; }
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:
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.
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.
I don't have any arguments to add other than: It adds a lot of complexity and potential confusion for (IMO) negligible gain.
I would really like to see actual use cases (and less foobar) because I truely can't think of valid ones.. For mutable constructs I would just use methods to change the state and for immutable constructs readonly
does the trick for me.
clone with
would be nice, but this works reasonably fine for me:
final readonly class SomeClass { public function __construct( public string $prop1, public bool $prop2, ) {} public function with( string $prop1 = null, bool $prop2 = null, ): self { return new self( $prop1 ?? $this->prop1, $prop2 ?? $this->prop2, ); } }
to be used with named arguments like
$someClass->with( prop1: 'changed', );
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.
Let us rather remove the writeonce
behavior from readonly
and add a separate writeonce
keyword.
The private(set)
syntax is also ugly.
Chain method on newly created objects without parentheses
The "pipe operator" |>
allows you to chain multiple function calls in a more convenient way.