Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103826
MIME-Version: 1.0
References: <20190124131514.CD9051000DB@smtp02.mail.de> <CAF+90c8O4DttLY3G=0H8d2fxizDcp61Xud4y2niJRgFPFqPc4g@mail.gmail.com>
In-Reply-To: <CAF+90c8O4DttLY3G=0H8d2fxizDcp61Xud4y2niJRgFPFqPc4g@mail.gmail.com>
Date: Thu, 24 Jan 2019 15:02:05 +0100
Message-ID: <CAOWwgpnY=DRRBHiOJX_CEKwxAb1wuTnOCfjy95B4emGbtqfQQw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: naitsirch@e.mail.de, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000080f651058034a888"
Subject: Re: [PHP-DEV] [RFC] New custom object serialization mechanism
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000080f651058034a888
Content-Type: text/plain; charset="UTF-8"

Thank you Nikita,

the RFC looks solid to me. Using magic methods makes perfect sense to allow
a smooth migration path.

We could enforce that if one of __serialize() or __unserialize() is
> defined, both have to be defined, to avoid running into such cases.


That would make sense a lot of sense to me.


> Maybe one could use `__normalize()` and `__denormalize()` [...]
>
I'd like that "serialization" appears in some form in the name
>

An idea: __pre_serialize / __post_unserialize
But __serialize/__unserialize are good to me.

Nicolas

--00000000000080f651058034a888--