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 downsides: - 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
