I do agree with Marco that this is a step in a wrong direction. Our
goal should be not ensuring that a prop is not rewritten outside, but
rather that it is not re-written at all. It makes no sense to rewrite
a property in majority of cases:
1. fields of an DTO - nay. Should be immutable instead. You never
change DTO, don't you?
2. injected services (like DB connection or an HTTP client) - nay.
Shouldn't ever be overwritten once an object containing them is
instantiated. Write-once / immutable is preferred.
3. data fields of an Entity-like object - looks like the only
reasonable case. However adding dedicated syntax for this is arguably
not much better that what we have now. It is already solvable with
standard getX() pattern, or with a single method returning a required
chunk of state as DTO.

So for me this does only solve the problem of having getters (or
dedicated methods) in #3, which is rare enough compared to other code,
and is already solvable with syntax existing nowadays already.
Introducing the new syntax, however, will have the following
- adding proper immutable / write-once properties to the language will
be met with much more resistance: "Why adding immutable if we have
private set already!"
- this will encourage using them in places where immutability (e.g.
via static analysis tool like Psalm) should be used instead (see #1
and #2).
- adding more advanced property accessors feature will be also likely
met with more resistance.

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to