Nikita Popov wrote on 24.01.2019 15:40: > On Thu, Jan 24, 2019 at 3:08 PM Larry Garfield <la...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
