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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
