Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104604
MIME-Version: 1.0
References: <CAF+90c_=u2NxcWA7tRYnr3RnYJfShNus4WYHTDmcqzAVHcWcoQ@mail.gmail.com>
 <bcdda760-5c86-e027-b6b2-a7970681b783@php.net> <CAF+90c-Ceup=rcox8JBzYRdq4LqgHBAUcmnu+k=J6FsETGt-hA@mail.gmail.com>
In-Reply-To: <CAF+90c-Ceup=rcox8JBzYRdq4LqgHBAUcmnu+k=J6FsETGt-hA@mail.gmail.com>
Date: Wed, 6 Mar 2019 14:41:28 +0100
Message-ID: <CAOWwgpmys1iA3+krPQdWN+BfsdiWWoi9UjeqXy3FhokE2OYJRA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000473b2905836d265d"
Subject: Re: [PHP-DEV] [VOTE] New custom object serialization mechanism
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000473b2905836d265d
Content-Type: text/plain; charset="UTF-8"

> How do people feel about deprecating Serializable in 7.4 and
> removing in 8.0 (not as part of this RFC but a separate one)? The
> deprecation warning would only be thrown if Serializable is implemented but
> the class has no __serialize/__unserialize. The timeline would be a bit
> aggressive in that we'd be introducing the replacement in the same release
> as the deprecation, something I'd usually try to avoid.
>

I'd feel fine. The plan is aggressive, but Serializable easily produces
broken payloads right now, so we need to move away from it as quickly as
possible.

You didn't mention it, but keeping __sleep/__wakeup as is in 7.4 is fine to
me: they do no harm. Deprecating them might be considered in 8.1, but they
don't need the same aggressive plan to me.

Nicolas

--000000000000473b2905836d265d--