Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Re: [RFC] New custom object serialization mechanism »

Re: [RFC] New custom object serialization mechanism

php.internals

Unnamed Person

7 years ago
On Thu, Jan 24, 2019 at 13:27 Nikita Popov <nikita.ppv@gmail.com> wrote: > Hi internals, > > I'd like to propose a new custom object serialization mechanism intended to > replace the broken Serializable interface: > > https://wiki.php.net/rfc/custom_object_serialization > > This was already previously discussed in https://externals.io/message/98834, > this just brings it into RFC form. The latest motivation for this is > https://bugs.php.net/bug.php?id=77302, a compatibility issue in 7.3 > affecting Symfony, caused by Serializable. We can't fix Serializable, but > we can at least make sure that a working alternative exists. > > Regards, > Nikita Hi. What happens if both `__serialize()` and `__wakeup()` are implemented? And another idea for the naming: Maybe one could use `__normalize()` and `__denormalize()`. Because the methods do not serialize themself, like the normalizer in the Symfony serializer component. Best regards ------------------------------------------------------------------------------------------------- FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT

Nikita Popov

7 years ago
On Thu, Jan 24, 2019 at 2:15 PM <naitsirch@e.mail.de> wrote:
> On Thu, Jan 24, 2019 at 13:27 Nikita Popov <nikita.ppv@gmail.com> > wrote: > > > Hi internals, > > > > I'd like to propose a new custom object serialization mechanism intended > to > > replace the broken Serializable interface: > > > > https://wiki.php.net/rfc/custom_object_serialization > > > > This was already previously discussed in > https://externals.io/message/98834, > > this just brings it into RFC form. The latest motivation for this is > > https://bugs.php.net/bug.php?id=77302, a compatibility issue in 7.3 > > affecting Symfony, caused by Serializable. We can't fix Serializable, but > > we can at least make sure that a working alternative exists. > > > > Regards, > > Nikita > > Hi. > > What happens if both `__serialize()` and `__wakeup()` are implemented? >
You mean if there are just those two methods, but not __unserialize() for example? In that case the array returned by __serialize() will be unserialized as object properties and __wakeup() will be called for finalization. In principle it's okay to use this combination, though it would be somewhat unusual. We could enforce that if one of __serialize() or __unserialize() is defined, both have to be defined, to avoid running into such cases. At least I don't see much legitimate use for combining __serialize() and __wakeup() or __sleep() and __unserialize(). And another idea for the naming: Maybe one could use `__normalize()` and
> `__denormalize()`. Because the methods do not serialize themself, like the > normalizer in the Symfony serializer component. >
I'd like that "serialization" appears in some form in the name, to make clear in what context this is used. Normalization is a fairly general term and could refer to any number of things. Nikita

Nicolas Grekas

7 years ago
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

Larry Garfield

7 years ago
On Thu, Jan 24, 2019, at 8:02 AM, Nicolas Grekas 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? --Larry Garfield

Nikita Popov

7 years ago
On Thu, Jan 24, 2019 at 3:08 PM Larry Garfield <larry@garfieldtech.com> wrote:
> On Thu, Jan 24, 2019, at 8:02 AM, Nicolas Grekas 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

Unnamed Person

7 years ago
Nikita Popov wrote on 24.01.2019 15:40:
> On Thu, Jan 24, 2019 at 3:08 PM Larry Garfield <larry@garfieldtech.com> > wrote: > >> On Thu, Jan 24, 2019, at 8:02 AM, Nicolas Grekas 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

Rowan Collins

7 years ago
On Thu, 24 Jan 2019 at 14:53, Thomas Bley <mails@thomasbley.de> wrote:
> 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(). >
That looks like basically the same methods as proposed, but with different names: class A has implemented toArray(), and it either recursively calling toArray() on other objects, or is returning those instances for default handling by serialize(). If the proposed functions were marked as a generic serialization interface, as Larry suggests, they would just be standardising this exact pattern. Regards,
-- Rowan Collins [IMSoP]