Hi internals,
I have opened voting on https://wiki.php.net/rfc/custom_object_serialization.
The vote will be open until 2019-03-15.
You can find the discussion thread for this proposal here:
https://externals.io/message/103823
Regards,
Nikita
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.
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
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
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.
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
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
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
Hi internals,
I have opened voting on
https://wiki.php.net/rfc/custom_object_serialization. The vote will be
open until 2019-03-15.You can find the discussion thread for this proposal here:
https://externals.io/message/103823Regards,
Nikita
Vote closed a bit late here ... the RFC is accepted with 20 votes in favor
and 7 against.
Regarding deprecation, I think I will target this at PHP 8. The new
mechanism will be there for the people who are running into the limits of
the existing one, but we probably don't need everybody to switch over right
this minute just yet.
Regards,
Nikita
Thanks for bringing this new serialization method to PHP 7.4, Nikita!
It would be nice if we could make this reusable beyond serialization. There
are two caveats that come to mind:
(...)
The __unserialize() method assumes an already constructed object on
which __unserialize() can be called, which we need due to the peculiar
limitations of serialization in PHP, but which is probably not very
convenient for other purposes, where the approach of __set_state() is more
useful.
I actually started working on a replacement for var_export(), that makes
use of __serialize() and __unserialize() methods when available, to
reconstruct an object:
https://github.com/brick/varexporter
It turns out that it works pretty well, here is an example output for an
object that implements these methods:
(static function() {
$class = new \ReflectionClass(\My\CustomClass::class);
$object = $class->newInstanceWithoutConstructor();
$object->__unserialize([
'foo' => 'Test',
'bar' => 1234
]);
return $object;
})()
And the good thing is, it can use these methods right now, without waiting
for PHP 7.4.
Feedback welcome!
Ben
Hi internals,
I have opened voting on
https://wiki.php.net/rfc/custom_object_serialization. The vote will be
open until 2019-03-15.You can find the discussion thread for this proposal here:
https://externals.io/message/103823Regards,
NikitaVote closed a bit late here ... the RFC is accepted with 20 votes in favor
and 7 against.Regarding deprecation, I think I will target this at PHP 8. The new
mechanism will be there for the people who are running into the limits of
the existing one, but we probably don't need everybody to switch over right
this minute just yet.Regards,
Nikita