Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Phasing out Serializable »

[RFC] Phasing out Serializable

php.internals

Nikita Popov

5 years ago
Hi internals, Picking up a loose thread: https://wiki.php.net/rfc/custom_object_serialization introduced a replacement for Serializable in PHP 7.4, so it's time to think about deprecating and removing the old mechanism: https://wiki.php.net/rfc/phase_out_serializable This RFC follows a rather conversative approach. In PHP 8.1 there will be a deprecation warning if Serializable is implemented without also implementing __serialize() and __unserialize(). In PHP 9.0, support for Serializable is dropped internally, and only the interface retained. In PHP 10.0 the interface is dropped as well. Regards, Nikita

Björn Larsson

5 years ago
Den 2020-12-07 kl. 15:11, skrev Nikita Popov:
> Hi internals, > > Picking up a loose thread: > https://wiki.php.net/rfc/custom_object_serialization introduced a > replacement for Serializable in PHP 7.4, so it's time to think about > deprecating and removing the old mechanism: > > https://wiki.php.net/rfc/phase_out_serializable > > This RFC follows a rather conversative approach. In PHP 8.1 there will be a > deprecation warning if Serializable is implemented without also > implementing __serialize() and __unserialize(). In PHP 9.0, support for > Serializable is dropped internally, and only the interface retained. In PHP > 10.0 the interface is dropped as well. > > Regards, > Nikita
Given that 10.0 lies maybe ten years in the future if we have a similar timeline like for 7.0 to 8.0. Is it then realistic to have such a long-term planning? For me it feels a bit more prudent to remove it completely in 9.0. Otherwise +1! r//Björn L

Nikita Popov

5 years ago
On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson <bjorn.x.larsson@telia.com> wrote:
> Den 2020-12-07 kl. 15:11, skrev Nikita Popov: > > > Hi internals, > > > > Picking up a loose thread: > > https://wiki.php.net/rfc/custom_object_serialization introduced a > > replacement for Serializable in PHP 7.4, so it's time to think about > > deprecating and removing the old mechanism: > > > > https://wiki.php.net/rfc/phase_out_serializable > > > > This RFC follows a rather conversative approach. In PHP 8.1 there will > be a > > deprecation warning if Serializable is implemented without also > > implementing __serialize() and __unserialize(). In PHP 9.0, support for > > Serializable is dropped internally, and only the interface retained. In > PHP > > 10.0 the interface is dropped as well. > > > > Regards, > > Nikita >
I had to slightly extend this RFC to also deprecate & remove the PDO::FETCH_SERIALIZE mode, which is based on Serializable. Doesn't seem to be a big loss, as this fetch mode isn't working correctly in the first place...
> Given that 10.0 lies maybe ten years in the future if we have a similar > timeline > like for 7.0 to 8.0. Is it then realistic to have such a long-term > planning? For me > it feels a bit more prudent to remove it completely in 9.0. > > Otherwise +1! >
I'd be also okay with dropping it entirely in PHP 9. That would mean that there is no prior deprecation warning if you implement it together with __serialize() and __unserialize() though, which is why I went with the proposed timeline. From my own (technical) perspective, the case is closed in PHP 9 either way, because that's where we can rip out support in unserialize(). Nikita

Nicolas Grekas

5 years ago
Hi Nikita,
> > > Picking up a loose thread: > > > https://wiki.php.net/rfc/custom_object_serialization introduced a > > > replacement for Serializable in PHP 7.4, so it's time to think about > > > deprecating and removing the old mechanism: > > > > > > https://wiki.php.net/rfc/phase_out_serializable > > > > > > This RFC follows a rather conversative approach. In PHP 8.1 there will > > be a > > > deprecation warning if Serializable is implemented without also > > > implementing __serialize() and __unserialize(). In PHP 9.0, support for > > > Serializable is dropped internally, and only the interface retained. In > > PHP > > > 10.0 the interface is dropped as well. >
thank you for the RFC, I fully support it!
> I had to slightly extend this RFC to also deprecate & remove the > PDO::FETCH_SERIALIZE mode, which is based on Serializable. Doesn't seem to > be a big loss, as this fetch mode isn't working correctly in the first > place... > > > > Given that 10.0 lies maybe ten years in the future if we have a similar > > timeline > > like for 7.0 to 8.0. Is it then realistic to have such a long-term > > planning? For me > > it feels a bit more prudent to remove it completely in 9.0. > > > > Otherwise +1! > > > > I'd be also okay with dropping it entirely in PHP 9. That would mean that > there is no prior deprecation warning if you implement it together with > __serialize() and __unserialize() though, which is why I went with the > proposed timeline. From my own (technical) perspective, the case is closed > in PHP 9 either way, because that's where we can rip out support in > unserialize(). >
I think it's critical to create a smooth path, and the one you propose is very sensible to me. We're not in a hurry to remove the interface. It should just be super clear what the direction is, and this path with a deprecation works well IMHO. Nicolas

Björn Larsson

5 years ago
Den 2020-12-07 kl. 16:49, skrev Nikita Popov:
> On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson <bjorn.x.larsson@telia.com> > wrote: > >> Den 2020-12-07 kl. 15:11, skrev Nikita Popov: >> >>> Hi internals, >>> >>> Picking up a loose thread: >>> https://wiki.php.net/rfc/custom_object_serialization introduced a >>> replacement for Serializable in PHP 7.4, so it's time to think about >>> deprecating and removing the old mechanism: >>> >>> https://wiki.php.net/rfc/phase_out_serializable >>> >>> This RFC follows a rather conversative approach. In PHP 8.1 there will >> be a >>> deprecation warning if Serializable is implemented without also >>> implementing __serialize() and __unserialize(). In PHP 9.0, support for >>> Serializable is dropped internally, and only the interface retained. In >> PHP >>> 10.0 the interface is dropped as well. >>> >>> Regards, >>> Nikita >> > > I had to slightly extend this RFC to also deprecate & remove the > PDO::FETCH_SERIALIZE mode, which is based on Serializable. Doesn't seem to > be a big loss, as this fetch mode isn't working correctly in the first > place... > > >> Given that 10.0 lies maybe ten years in the future if we have a similar >> timeline >> like for 7.0 to 8.0. Is it then realistic to have such a >> long-term planning? For me it feels a bit more prudent to remove it >> completely in 9.0. >> >> Otherwise +1! >> > > I'd be also okay with dropping it entirely in PHP 9. That would mean that > there is no prior deprecation warning if you implement it together with > __serialize() and __unserialize() though, which is why I went with the > proposed timeline. From my own (technical) perspective, the case is closed > in PHP 9 either way, because that's where we can rip out support in > unserialize(). > > Nikita >
Not sure I understand why no deprecation warning is needed in 8.1, if removing completely in 9.0? Anyway, my main objection towards the proposed timeline is not so much about the functionality removed. It's more related with that I think an RFC that mandates what should happen in 10.0, maybe 10 years into the future feels a bit farfetched. Of course there could be exceptions for RFC's targeting PHP 10.0, but then I think it should be for something big, like replacing the SPL library etc. r//Björn L

Paul

5 years ago
> an RFC that mandates what should happen in 10.0, maybe > 10 years into the future feels a bit farfetched.
It's more of a default unless another RFC changes the plan rather than a mandate. Given the plan here it seems a reasonable default.

Nikita Popov

5 years ago
On Tue, Dec 15, 2020 at 12:14 AM Björn Larsson <bjorn.x.larsson@telia.com> wrote:
> Den 2020-12-07 kl. 16:49, skrev Nikita Popov: > > On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson <bjorn.x.larsson@telia.com> > > wrote: > > > >> Den 2020-12-07 kl. 15:11, skrev Nikita Popov: > >> > >>> Hi internals, > >>> > >>> Picking up a loose thread: > >>> https://wiki.php.net/rfc/custom_object_serialization introduced a > >>> replacement for Serializable in PHP 7.4, so it's time to think about > >>> deprecating and removing the old mechanism: > >>> > >>> https://wiki.php.net/rfc/phase_out_serializable > >>> > >>> This RFC follows a rather conversative approach. In PHP 8.1 there will > >> be a > >>> deprecation warning if Serializable is implemented without also > >>> implementing __serialize() and __unserialize(). In PHP 9.0, support for > >>> Serializable is dropped internally, and only the interface retained. In > >> PHP > >>> 10.0 the interface is dropped as well. > >>> > >>> Regards, > >>> Nikita > >> > > > > I had to slightly extend this RFC to also deprecate & remove the > > PDO::FETCH_SERIALIZE mode, which is based on Serializable. Doesn't seem > to > > be a big loss, as this fetch mode isn't working correctly in the first > > place... > > > > > >> Given that 10.0 lies maybe ten years in the future if we have a similar > >> timeline >> like for 7.0 to 8.0. Is it then realistic to have such a > >> long-term planning? For me it feels a bit more prudent to remove it > >> completely in 9.0. > >> > >> Otherwise +1! > >> > > > > I'd be also okay with dropping it entirely in PHP 9. That would mean that > > there is no prior deprecation warning if you implement it together with > > __serialize() and __unserialize() though, which is why I went with the > > proposed timeline. From my own (technical) perspective, the case is > closed > > in PHP 9 either way, because that's where we can rip out support in > > unserialize(). > > > > Nikita > > > Not sure I understand why no deprecation warning is needed in 8.1, > if removing completely in 9.0? >
The current proposed timeline only removes in PHP 9.0 what was deprecated in PHP 8.1. Possibly I'm misunderstanding what you have in mind here. Anyway, my main objection towards the proposed timeline is not so
> much about the functionality removed. It's more related with that > I think an RFC that mandates what should happen in 10.0, maybe > 10 years into the future feels a bit farfetched. > > Of course there could be exceptions for RFC's targeting PHP 10.0, > but then I think it should be for something big, like replacing > the SPL library etc. >
I'm not sure I understand what your actual concern here is. Yes, it's a long-term plan, but why is that a problem? Why should long-term planning only be limited to major changes? Even a simple deprecation already works on a 5 year timeline, between deprecation and removal. Of course, I have no idea whether I'll still be involved with the PHP project in ten years time, but I suspect there will always be someone who enjoys deleting deprecated code to carry out the will ;) Regards, Nikita

Björn Larsson

5 years ago
Den 2021-01-06 kl. 17:51, skrev Nikita Popov:
> On Tue, Dec 15, 2020 at 12:14 AM Björn Larsson > <bjorn.x.larsson@telia.com <mailto:bjorn.x.larsson@telia.com>> wrote: > > Den 2020-12-07 kl. 16:49, skrev Nikita Popov: > > On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson > <bjorn.x.larsson@telia.com <mailto:bjorn.x.larsson@telia.com>> > > wrote: > > > >> Den 2020-12-07 kl. 15:11, skrev Nikita Popov: > >> > >>> Hi internals, > >>> > >>> Picking up a loose thread: > >>> https://wiki.php.net/rfc/custom_object_serialization > <https://wiki.php.net/rfc/custom_object_serialization> introduced a > >>> replacement for Serializable in PHP 7.4, so it's time to think > about > >>> deprecating and removing the old mechanism: > >>> > >>> https://wiki.php.net/rfc/phase_out_serializable > <https://wiki.php.net/rfc/phase_out_serializable> > >>> > >>> This RFC follows a rather conversative approach. In PHP 8.1 > there will > >> be a > >>> deprecation warning if Serializable is implemented without also > >>> implementing __serialize() and __unserialize(). In PHP 9.0, > support for > >>> Serializable is dropped internally, and only the interface > retained. In > >> PHP > >>> 10.0 the interface is dropped as well. > >>> > >>> Regards, > >>> Nikita > >> > > > > I had to slightly extend this RFC to also deprecate & remove the > > PDO::FETCH_SERIALIZE mode, which is based on Serializable. > Doesn't seem to > > be a big loss, as this fetch mode isn't working correctly in the > first > > place... > > > > > >> Given that 10.0 lies maybe ten years in the future if we have a > similar > >> timeline >> like for 7.0 to 8.0. Is it then realistic to have > such a > >> long-term planning? For me it feels a bit more prudent to remove it > >> completely in 9.0. > >> > >> Otherwise +1! > >> > > > > I'd be also okay with dropping it entirely in PHP 9. That would > mean that > > there is no prior deprecation warning if you implement it > together with > > __serialize() and __unserialize() though, which is why I went > with the > > proposed timeline. From my own (technical) perspective, the case > is closed > > in PHP 9 either way, because that's where we can rip out support in > > unserialize(). > > > > Nikita > > > Not sure I understand why no deprecation warning is needed in 8.1, > if removing completely in 9.0? > > The current proposed timeline only removes in PHP 9.0 what was > deprecated in PHP 8.1. Possibly I'm misunderstanding what you have in > mind here.
Ok, then I read it wrong, completely fine with above.
> > Anyway, my main objection towards the proposed timeline is not so > much about the functionality removed. It's more related with that > I think an RFC that mandates what should happen in 10.0, maybe > 10 years into the future feels a bit farfetched. > > Of course there could be exceptions for RFC's targeting PHP 10.0, > but then I think it should be for something big, like replacing > the SPL library etc. > > > I'm not sure I understand what your actual concern here is. Yes, it's > a long-term plan, but why is that a problem? Why should long-term > planning only be limited to major changes? Even a simple deprecation > already works on a 5 year timeline, between deprecation and removal. > Of course, I have no idea whether I'll still be involved with the PHP > project in ten years time, but I suspect there will always be someone > who enjoys deleting deprecated code to carry out the will ;)
Not sure we had RFC's earlier with a ten year lifespan. So I have a concern about how realistic it would be ;-) The RFC is targetting two major versions, think it would be cleaner to target only one of them, not two. Now we have this RFC for 8.1 and we remove it it in the first step in 9.0 followed by removing it completely in 10.0. One motive for this as I understand it, is the <7.4 support. Anyway, come to think on the RFC "Remove PHP 4 Constructors" which targeted 7.0 and then it was removed completely in 8.0. Also thinking on the 7.4 deprecation RFC, where the items was removed in 8.0. So is it by having this RFC targeting 8.1, we get five extra years or is it the <7.4 support? r//Björn L

Björn Larsson

5 years ago
Den 2021-01-08 kl. 00:23, skrev Björn Larsson:
> Den 2021-01-06 kl. 17:51, skrev Nikita Popov: > >> On Tue, Dec 15, 2020 at 12:14 AM Björn Larsson >> <bjorn.x.larsson@telia.com <mailto:bjorn.x.larsson@telia.com>> wrote: >> >> Den 2020-12-07 kl. 16:49, skrev Nikita Popov: >> > On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson >> <bjorn.x.larsson@telia.com <mailto:bjorn.x.larsson@telia.com>> >> > wrote: >> > >> >> Den 2020-12-07 kl. 15:11, skrev Nikita Popov: >> >> >> >>> Hi internals, >> >>> >> >>> Picking up a loose thread: >> >>> https://wiki.php.net/rfc/custom_object_serialization >> <https://wiki.php.net/rfc/custom_object_serialization> introduced a >> >>> replacement for Serializable in PHP 7.4, so it's time to >> think about >> >>> deprecating and removing the old mechanism: >> >>> >> >>> https://wiki.php.net/rfc/phase_out_serializable >> <https://wiki.php.net/rfc/phase_out_serializable> >> >>> >> >>> This RFC follows a rather conversative approach. In PHP 8.1 >> there will >> >> be a >> >>> deprecation warning if Serializable is implemented without also >> >>> implementing __serialize() and __unserialize(). In PHP 9.0, >> support for >> >>> Serializable is dropped internally, and only the interface >> retained. In >> >> PHP >> >>> 10.0 the interface is dropped as well. >> >>> >> >>> Regards, >> >>> Nikita >> >> >> > >> > I had to slightly extend this RFC to also deprecate & remove the >> > PDO::FETCH_SERIALIZE mode, which is based on Serializable. >> Doesn't seem to >> > be a big loss, as this fetch mode isn't working correctly in >> the first >> > place... >> > >> > >> >> Given that 10.0 lies maybe ten years in the future if we have >> a similar >> >> timeline >> like for 7.0 to 8.0. Is it then realistic to have >> such a >> >> long-term planning? For me it feels a bit more prudent to >> remove it >> >> completely in 9.0. >> >> >> >> Otherwise +1! >> >> >> > >> > I'd be also okay with dropping it entirely in PHP 9. That would >> mean that >> > there is no prior deprecation warning if you implement it >> together with >> > __serialize() and __unserialize() though, which is why I went >> with the >> > proposed timeline. From my own (technical) perspective, the >> case is closed >> > in PHP 9 either way, because that's where we can rip out support in >> > unserialize(). >> > >> > Nikita >> > >> Not sure I understand why no deprecation warning is needed in 8.1, >> if removing completely in 9.0? >> >> The current proposed timeline only removes in PHP 9.0 what was >> deprecated in PHP 8.1. Possibly I'm misunderstanding what you have in >> mind here. > > Ok, then I read it wrong, completely fine with above. >> >> Anyway, my main objection towards the proposed timeline is not so >> much about the functionality removed. It's more related with that >> I think an RFC that mandates what should happen in 10.0, maybe >> 10 years into the future feels a bit farfetched. >> >> Of course there could be exceptions for RFC's targeting PHP 10.0, >> but then I think it should be for something big, like replacing >> the SPL library etc. >> >> >> I'm not sure I understand what your actual concern here is. Yes, it's >> a long-term plan, but why is that a problem? Why should long-term >> planning only be limited to major changes? Even a simple deprecation >> already works on a 5 year timeline, between deprecation and removal. >> Of course, I have no idea whether I'll still be involved with the PHP >> project in ten years time, but I suspect there will always be someone >> who enjoys deleting deprecated code to carry out the will ;) > > > Not sure we had RFC's earlier with a ten year lifespan. So I have > a concern about how realistic it would be ;-) The RFC is targetting > two major versions, think it would be cleaner to target only one > of them, not two. > > Now we have this RFC for 8.1 and we remove it it in the first step in > 9.0 followed by removing it completely in 10.0. One motive for this > as I understand it, is the <7.4 support. > > Anyway, come to think on the RFC "Remove PHP 4 Constructors" > which targeted 7.0 and then it was removed completely in 8.0. > Also thinking on the 7.4 deprecation RFC, where the items was > removed in 8.0. > > So is it by having this RFC targeting 8.1, we get five extra years > or is it the <7.4 support? > > r//Björn L >
After thinking a bit more my objection is twofold. One is the long timeline, targetting 10.0 and at least for me it's not clear why not having 9.0 as the endpoint is good enough. Secondly, we introduce a three step approach, targetting both 8.1, 9.0 and 10.0. Is this something that also could come into play for other deprecations and what is then the criteria for it? Like the planned 8.1 deprecations: - https://wiki.php.net/rfc/deprecations_php_8_0 r//Björn L

Nicolas Grekas

5 years ago
Hello Nikita, Picking up a loose thread:
> https://wiki.php.net/rfc/custom_object_serialization introduced a > replacement for Serializable in PHP 7.4, so it's time to think about > deprecating and removing the old mechanism: > > https://wiki.php.net/rfc/phase_out_serializable > > This RFC follows a rather conversative approach. In PHP 8.1 there will be a > deprecation warning if Serializable is implemented without also > implementing __serialize() and __unserialize(). In PHP 9.0, support for > Serializable is dropped internally, and only the interface retained. In PHP > 10.0 the interface is dropped as well. >
Reading the comments in this thread, the three-step approach is surprising to some. What about deprecating in 8.1 and removing in 9.0 instead? The stub Serializable interface can be provided in userland via a polyfill, if anyone really needs a smoother transition plan. I'd really like to see this deprecation in 8.1, to stop ppl from writing new implementations of Serializable asap. Nicolas

Nikita Popov

5 years ago
On Tue, Mar 23, 2021 at 5:01 PM Nicolas Grekas <nicolas.grekas+php@gmail.com> wrote:
> Hello Nikita, > > > Picking up a loose thread: >> https://wiki.php.net/rfc/custom_object_serialization introduced a >> replacement for Serializable in PHP 7.4, so it's time to think about >> deprecating and removing the old mechanism: >> >> https://wiki.php.net/rfc/phase_out_serializable >> >> This RFC follows a rather conversative approach. In PHP 8.1 there will be >> a >> deprecation warning if Serializable is implemented without also >> implementing __serialize() and __unserialize(). In PHP 9.0, support for >> Serializable is dropped internally, and only the interface retained. In >> PHP >> 10.0 the interface is dropped as well. >> > > > Reading the comments in this thread, the three-step approach is surprising > to some. > What about deprecating in 8.1 and removing in 9.0 instead? > The stub Serializable interface can be provided in userland via a > polyfill, if anyone really needs a smoother transition plan. > > I'd really like to see this deprecation in 8.1, to stop ppl from writing > new implementations of Serializable asap. >
I've updated the RFC to follow this suggestion. Björn, please tell me whether this addresses your concerns. Regards, Nikita

Björn Larsson

5 years ago
Den 2021-03-23 kl. 18:19, skrev Nikita Popov:
> On Tue, Mar 23, 2021 at 5:01 PM Nicolas Grekas > <nicolas.grekas+php@gmail.com <mailto:nicolas.grekas%2Bphp@gmail.com>> > wrote: > > Hello Nikita, > > > Picking up a loose thread: > https://wiki.php.net/rfc/custom_object_serialization > <https://wiki.php.net/rfc/custom_object_serialization> > introduced a > replacement for Serializable in PHP 7.4, so it's time to think > about > deprecating and removing the old mechanism: > > https://wiki.php.net/rfc/phase_out_serializable > <https://wiki.php.net/rfc/phase_out_serializable> > > This RFC follows a rather conversative approach. In PHP 8.1 > there will be a > deprecation warning if Serializable is implemented without also > implementing __serialize() and __unserialize(). In PHP 9.0, > support for > Serializable is dropped internally, and only the interface > retained. In PHP > 10.0 the interface is dropped as well. > > > > Reading the comments in this thread, the three-step approach is > surprising to some. > What about deprecating in 8.1 and removing in 9.0 instead? > The stub Serializable interface can be provided in userland via a > polyfill, if anyone really needs a smoother transition plan. > > I'd really like to see this deprecation in 8.1, to stop ppl from > writing new implementations of Serializable asap. > > > I've updated the RFC to follow this suggestion. Björn, please tell me > whether this addresses your concerns. > > Regards, > Nikita >
Yes it does, very good! r//Björn L

Côme Chilliet

5 years ago
Le Tue, 23 Mar 2021 17:01:40 +0100, Nicolas Grekas <nicolas.grekas+php@gmail.com> a écrit :
> Picking up a loose thread: > > https://wiki.php.net/rfc/custom_object_serialization introduced a > > replacement for Serializable in PHP 7.4, so it's time to think about > > deprecating and removing the old mechanism: > > > > https://wiki.php.net/rfc/phase_out_serializable > > > > This RFC follows a rather conversative approach. In PHP 8.1 there will be a > > deprecation warning if Serializable is implemented without also > > implementing __serialize() and __unserialize(). In PHP 9.0, support for > > Serializable is dropped internally, and only the interface retained. In PHP > > 10.0 the interface is dropped as well. > >
It is not clear neither in https://wiki.php.net/rfc/custom_object_serialization nor in the documentation if it is possible to call parent::__serialize() to only add a few fields to serialization. Is this legal/correct/useful: public __serialize ( ) : array { $data = parent::__serialize(); $data['specialField'] = $data['special']->complicatedStuff(); unset($data['special']); return $data; } public __unserialize ( array $data ) : void { $data['special'] = new SpecialComplicatedThing($data['specialField']); unset($data['specialField']); parent::__unserialize($data); } (And as I understand it, it means declaring __unserialize to do something after parent::__unserialize() would be the same as declaring __wakeup?)

Nikita Popov

5 years ago
On Wed, Mar 24, 2021 at 10:38 AM Côme Chilliet < come.chilliet@fusiondirectory.org> wrote:
> Le Tue, 23 Mar 2021 17:01:40 +0100, > Nicolas Grekas <nicolas.grekas+php@gmail.com> a écrit : > > Picking up a loose thread: > > > https://wiki.php.net/rfc/custom_object_serialization introduced a > > > replacement for Serializable in PHP 7.4, so it's time to think about > > > deprecating and removing the old mechanism: > > > > > > https://wiki.php.net/rfc/phase_out_serializable > > > > > > This RFC follows a rather conversative approach. In PHP 8.1 there will > be a > > > deprecation warning if Serializable is implemented without also > > > implementing __serialize() and __unserialize(). In PHP 9.0, support for > > > Serializable is dropped internally, and only the interface retained. > In PHP > > > 10.0 the interface is dropped as well. > > > > > It is not clear neither in > https://wiki.php.net/rfc/custom_object_serialization > nor in the documentation if it is possible to call parent::__serialize() > to > only add a few fields to serialization. > > Is this legal/correct/useful: > > public __serialize ( ) : array > { > $data = parent::__serialize(); > $data['specialField'] = $data['special']->complicatedStuff(); > unset($data['special']); > return $data; > } > > public __unserialize ( array $data ) : void > { > $data['special'] = new SpecialComplicatedThing($data['specialField']); > unset($data['specialField']); > parent::__unserialize($data); > } >
Yes, this is possible. Regards, Nikita