On Fri, Jul 18, 2025, at 11:29 AM, Tim Düsterhus wrote: >> // New code in 8.5: >> >> $p = new PositivePoint(3, 4); >> $p2 = clone($p, ['x' => -10]); > > This is not legal code in PHP 8.5. Clone-with respects visibility and > since your asymmetric visibility RFC included the change, you are > probably aware that `readonly` implies `protected(set)`. > > 5. > >> but are now necessary to ensure that invariants are enforced. > > And therefore with PHP 8.5 hooks are not necessary to enforce > invariants, except in the rare case where a `public(set) readonly` > property is used.
This is a valid point, thanks. I have updated the example to use `public(set)`, and note that it means many withX() methods can be eliminated, as their restrictions can be placed on the property instead. Note to self: public(clone) ... > 6. > >> So no guarantees are softened by this RFC. > > Yes, they are. Unless `__get()` is implemented on a class (which is > explicitly visible as part of the public API), readonly guarantees the > immutability of identity. Which would also be guaranteed with the "refers to the backing value" proposal, which you also rejected. Does readonly refer to the physical value (backing value, object identity) or the "value returned"? That wasn't a distinction that mattered in 8.1 when readonly was introduced, though now it does. If yes, then all that needs to be protected is the backing value, so get hooks that respect that should be fine. Does readonly refer to the value returned? If so, that's already been broken since the beginning because the property can be a mutable object, so trusting the data returned to be "the same" is already not safe. At a conceptual level, we need to decide what readonly means. There is clearly no consensus on that right now, and that's going to cause problems any time we touch readonly, not just this RFC. >> While that is an interesting idea that has been floated a few times, it has >> enough complexities and edge cases of its own to address that we feel it is >> out of scope. > > While it certainly is your right as the RFC authors to consider certain > things out of scope for an RFC, I strongly oppose the notion of shipping > something that is strictly inferior and comes with obvious semantic > issues due to perceived complexity of another solution and then > following up with the proper solution that has already been identified. > As I've outlined in my previous emails, I found defining semantics for > an 'init' hook straight-forward when looking at how PHP works as of today. I suppose this is a valid argument, given that readonly was implemented because Nikita felt the proper solution of full aviz would be too complex so went with the simpler solution, which, turns out, is strictly inferior and comes with obvious semantic issues. > After reading through the discussion, it seems the only argument against > the 'init' hook is perceived complexity. It is not at all clear to me > why this means that we must now rush something with clear issues into > PHP 8.5. At this point, I fully expect the 'get' part of the RFC to not pass. Someone else is welcome to then work on an init hook. The seemingly less controversial 'set' hook still has considerable value on its own, and hopefully that passes. --Larry Garfield
