Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104607
To: "'Nikita Popov'" <nikita.ppv@gmail.com>,
	"'Sebastian Bergmann'" <sebastian@php.net>
Cc: "'PHP internals'" <internals@lists.php.net>
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: Thu, 7 Mar 2019 00:21:12 +0800
Message-ID: <000601d4d438$9d854140$d88fc3c0$@jhdxr.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQH5svmpZ2FSTuu/h8iPodTmDRq0IwL5qxyKAfTbob6ljZM+cA==
Content-Language: zh-cn
Feedback-ID: Yeas:jhdxr.com:qybgforeign:qybgforeign1
Subject: RE: [PHP-DEV] [VOTE] New custom object serialization mechanism
From: me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)

I voted no for similar reason. I understand the problem we have, but I =
really don't like the idea that just introduce a new method, well =
actually a pair of new methods, to solve this problem, without any plan =
to stop userland developer from the wrong use case. The deprecating plan =
also sounds too rush and aggressive for me. =
Serialize/unserialize/__sleep/__wakeup are wide used, and deprecating or =
removing them will be a huge BC break.=20

PHP 8 is a revolution version IMO, so if a RFC targeting PHP 8 propose =
to deprecate or removing those 4 methods, I will vote yes. But at the =
same time, I'd like to ask, is it possible to show warnings only if =
potential broken detected, e.g. serialize with reference, or parent:: =
serialize is called.

Regards,
CHU Zhaowei

-----Original Message-----
From: Nikita Popov <nikita.ppv@gmail.com>=20
Sent: Tuesday, March 5, 2019 8:35 PM
To: Sebastian Bergmann <sebastian@php.net>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [VOTE] New custom object serialization mechanism

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=20
> 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