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
