[RFC] New custom object serialization mechanism View as Markdown

Nikita Popov wrote on 24.01.2019 15:40:

On Thu, Jan 24, 2019 at 3:08 PM Larry Garfield larry@garfieldtech.com
wrote:

Thank you Nikita,

the RFC looks solid to me. Using magic methods makes perfect sense to
allow
a smooth migration path.

We could enforce that if one of __serialize() or __unserialize() is

defined, both have to be defined, to avoid running into such cases.

That would make sense a lot of sense to me.

Maybe one could use __normalize() and __denormalize() [...]

I'd like that "serialization" appears in some form in the name

An idea: __pre_serialize / __post_unserialize
But __serialize/__unserialize are good to me.

Nicolas

Given that these methods would not be producing/consuming strings but a
de-classed representation of the object, I agree that it's closer to
"normalize" as Symfony uses the term. We don't have to use that name
specifically but something other than serialize/deserialize seems logical.

Also, that in turn suggests that the same mechanism could be leveraged for
formats other than the C (or 0? It's referred to both ways in the RFC)
format we all know and grudgingly accept. Eg, it feels an awful lot like
JsonSerializable (which is for serialize only, but also returns an array),
and I can definitely see uses for a standard intermediary format that could
be encoded to C-serialized, JSON, or XML, or whatever else. Is there some
way that we could allow other systems to hook into it cleanly, such that it
becomes a common intermediary format for a variety of stringified formats?

Thanks for bringing this up. We do have a bit of a proliferation of
different serialization-related (in the wider sense of the word) methods:

• __sleep() and __wakeup()
• Serializable
• JsonSerializable
• __set_state()

It would be nice if we could make this reusable beyond serialization. There
are two caveats that come to mind:

• While __serialize() just returns an array, the same as JsonSerializable,
  this does not necessarily mean that they can be combined. PHP's
  serialization mechanism is much more powerful in what is can represent, so
  the return values of __serialize() and JsonSerializable::jsonSerialize()
  might well want to be different. The latter should in particular probably
  not include any non-trivial objects.
• The __unserialize() method assumes an already constructed object on
  which __unserialize() can be called, which we need due to the peculiar
  limitations of serialization in PHP, but which is probably not very
  convenient for other purposes, where the approach of __set_state() is more
  useful.

Nikita

Thanks for the rfc and all your contributions!

• __sleep() and __wakeup()
• Serializable
• JsonSerializable
• __set_state()

To me it's not clear why we need all these methods, for example:

$a = new A();
$aSerialized = serialize($a->toArray());
$aRestored = A::createFromArray(unserialize($aSerialized));

Apart from security problems, problems with versioning and unreadable data in databases,
I don't see many benefits from using serialize()/unserialize().

Regards
Thomas