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'; }
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', );
Let us rather remove the writeonce
behavior from readonly
and add a separate writeonce
keyword.
The private(set)
syntax is also ugly.
I like the idea behind this RFC, maybe the syntax is not my favourite, but it's ok.
This RFC proposes a way to have multi-line short closures — closures that don't need explicit use
statements, but can still have multiple lines and a return statement.
Interface Default Methods improves backwards compatibility when changing interfaces, but also add a way to have multi-inheritance in PHP.
The "pipe operator" |>
allows you to chain multiple function calls in a more convenient way.