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 On Thu, 21 Mar 2019 at 15:20, Nikita Popov <nikita....@gmail.com> wrote: > On Fri, Mar 1, 2019 at 4:08 PM Nikita Popov <nikita....@gmail.com> wrote: > > > 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 > > > > 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 >
