Re: [PHP-DEV] [RFC] Readonly Property Defaults

Hi

On 2026-07-09 21:18, Nick Sdot wrote:
>> 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.

That probably depends a little on the definition of “prevent”. 
Technically you could implement `__unserialize()`, sure. But you would 
be unable to unserialize into some of properties, which the native 
unserializer would be able to.

> 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.

Yes, I agree. clone-with already allows for the creation of object with 
a different value than the default, so allowing this for 
`__unserialize()` doesn't provide any new weird capabilities that result 
in inconsistencies.

------

As for the RFC, I have one more thing you could clarify: When using 
constructor property promotion, the default value will remain the 
default value of the parameter only and not suddenly also become the 
default of a property. It's a bit orthogonal to this RFC, and I find it 
reasonably obvious. But spelling it out to refresh everyone’s mind is 
probably a good thing nevertheless.

Other than that, I don't have any further comments on the RFC and in 
particular I don't see any more issues this would cause. Nevertheless, 
I'm probably team “Abstain” when it goes to vote :-)

Best regards
Tim Düsterhus