Re: [RFC] New custom object serialization mechanism

Le jeu. 24 janv. 2019 à 15:18, Sebastian Bergmann <sebastian@php.net> a écrit : > Am 24.01.2019 um 15:09 schrieb Marco Pivetta: > > Not really fussed about having another implicit interface for > serialization > > (via magic methods). > > I second that emotion. > The more I think about it, the more I'm convinced we should *not* add an interface for that. An interface defines a semantics - something that an API tpoa domain and that ppl can type-hint for to get a specific implementation of that API.Here, both aspects are not desired: we don't want ppl to type-hint for e.g. Serializable - and too bad it exists because I've already seen ppl think: "hey, I'll type-hint or extend it to express I want a serializable thing". BUT that's *not* the contract of Serializable or any variant of it because: 1. *any* PHP object is serializable 2. Serializable it well allowed to throw an exception to exactly *forbid* an object from being serialized. From this reasoning, I conclude that we really want magic methods here because what we need is a *behavior*. We want to hook into the engine to benefit from some special features it provides. That's what all magic methods are about and hooking into serialize()/unserialize() is not different. The parallel with the Symfony Serializer is interesting but it stop here: we don't need any help from core to build it. We should not seek for that goal IMHO as it blur the lines of what we're needing: a core primitive to build more useful things. Magic methods would just provide that, without polluting the semantics space. My 2cts, Nicolas