Re: [PHP-DEV] [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