Re: [RFC] New custom object serialization mechanism

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