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
