Re: [RFC] Readonly Property Defaults

Hey Tim On 09.07.26 20:12, Tim Düsterhus wrote:

Hi On 2026-07-09 13:58, Nick Sdot wrote:

At the time __unserialize is called the object exists, and the property is initialised with the default value. So it fails in the same way a re-assignment in the constructor or reflection setValue() will fail. So, I wouldn't say "not a situation we have so far", but agree that spelling it out cannot be wrong. RFC section is updated, and your PR comment example added as a test!

Yes, it would be a situation we do not yet have so far: As far as I can tell there is no way for a readonly property to be preinitialized when unserialization happens. This means that it is not not observable that the non-hooked serialization path ignores readonly. What is effectively guaranteed right now is that using a custom __unserialize() hook that loops over the given array and assigns all properties will behave identically to non-hooked serialization. This would no longer be the case as of this RFC. There is two options here: - The non-hooked unserialization path must also error out when trying to unserialize into a readonly property with a default value. - __unserialize() must be able to unserialize into a readonly property with a default value, similarly to __clone(). But the current situation of “__unserialize() is less powerful than the standard unserialization” is not acceptable, because it prevents introducing __unserialize() on a class with a readonly property with default values.

It would not really have prevented using __unserialize() on a class with a readonly property with default values. But fair, I don't have a strong opinion here. Given that clone-with also allows modification of already initialised readonly properties your proposed option #2 is sound. I updated the PR and RFC

Best regards Tim Düsterhus

-- Cheers Nick