On Tue, Feb 19, 2019 at 11:42 AM Nicolas Grekas < nicolas.grekas+...@gmail.com> wrote:
> > > 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. > As there hasn't been further input here, I'd like to go forward with the RFC as-is and plan to start voting by Friday. Nikita
