Le mar. 19 févr. 2019 à 11:31, Nikita Popov <nikita....@gmail.com> a écrit :
> On Mon, Feb 18, 2019 at 4:12 PM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> Hi Nikita, >> >> 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. >>> >> >> Is there anything we can to do to help the RFC move forward? I'm spending >> a great deal of time removing Serializable from the Symfony code base. It's >> not pretty nor fun... but we have no choice since as ppl move to PHP 7.3, >> they can now spot when the current mechanism is breaking their serialized >> payloads (typically from user objects put in the session storage). >> >> About interface vs magic methods, technicaly, we can work with an >> interface provided by PHP core, so that if that's a blocker for voters to >> approve the RFC, let's do it - the current situation is really aweful :). >> FYI, I found myself implementing some getState()/setState() methods of my >> own, decoupled from the underlying mechanisms used by PHP. That allows me >> to still use Serializable for BC reasons when needed, or move to __sleep >> when possible, then move to the new 7.4 style when ready, without requiring >> any changes from the consumer POV. That's a good illustration of what I >> meant in my previous email: domain-specific interfaces in everyone's code >> is a better design as it allows better decoupling. It's also a better >> design to express that "instances of this interface of mine MUST be >> serializable". IMHO. >> >> Nicolas >> > > I think for me the main open question here is whether we want to just > handle the serialization issue or try to come up with something more > general. If we limit this to just serialization, then the design should > stay as-is -- for all the reasons you have already outlined, using an > interface for this is inappropriate. > > For a more general mechanism, I think we would need something along the > lines of (ignoring naming): > > interface GetState { > public function getState(string $purpose): array; > } > interface SetState { > public function setState(array $data, string $purpose): void; > } > > We need separate interfaces for get/set to properly cater to cases like > JSON, where only get is meaningful (right now). We need the $purpose > argument to allow different state representations for different purposes, > e.g. JSON will often need more preparation than PHP serialization. The > $purpose argument is a string, to allow extension for custom purposes. > > Seeing that, this is really not something I would feel comfortable with > introducing in core PHP. Our track record for introducing reusable > general-purpose interfaces is not exactly stellar (say, did you hear about > SplObserver and SplSubject?) and I wouldn't want to do this without seeing > the concept fleshed out extensively in userland first. > > Nikita > I think the per-purpose representation logic doesn't belong to each classes. Symfony Serializer does it completly from the outside, and I think that's a much better design. I'm on the side this should not be in PHP code indeed. Nicolas
