Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104586
MIME-Version: 1.0
References: <CAF+90c_=u2NxcWA7tRYnr3RnYJfShNus4WYHTDmcqzAVHcWcoQ@mail.gmail.com>
 <bcdda760-5c86-e027-b6b2-a7970681b783@php.net>
In-Reply-To: <bcdda760-5c86-e027-b6b2-a7970681b783@php.net>
Date: Tue, 5 Mar 2019 13:35:25 +0100
Message-ID: <CAF+90c-Ceup=rcox8JBzYRdq4LqgHBAUcmnu+k=J6FsETGt-hA@mail.gmail.com>
To: Sebastian Bergmann <sebastian@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a0d4ce0583581cea"
Subject: Re: [PHP-DEV] [VOTE] New custom object serialization mechanism
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000a0d4ce0583581cea
Content-Type: text/plain; charset="UTF-8"

On Tue, Mar 5, 2019 at 1:18 PM Sebastian Bergmann <sebastian@php.net> wrote:

> Am 01.03.2019 um 16:08 schrieb Nikita Popov:
> > I have opened voting on
> https://wiki.php.net/rfc/custom_object_serialization.
> > The vote will be open until 2019-03-15.
>
> I voted "No" because this adds a third mechanism without a concrete plan
> to phase out the existing two mechanisms.
>

Good concern. 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.

Nikita

--000000000000a0d4ce0583581cea--