Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103827
User-Agent: Cyrus-JMAP/3.1.5-766-ge2be361-fmstable-20190123v1
Message-ID: <96949d28-1b59-4d8b-9db7-6c5047d180f7@www.fastmail.com>
In-Reply-To: 
 <CAOWwgpnY=DRRBHiOJX_CEKwxAb1wuTnOCfjy95B4emGbtqfQQw@mail.gmail.com>
References: <20190124131514.CD9051000DB@smtp02.mail.de>
 <CAF+90c8O4DttLY3G=0H8d2fxizDcp61Xud4y2niJRgFPFqPc4g@mail.gmail.com>
 <CAOWwgpnY=DRRBHiOJX_CEKwxAb1wuTnOCfjy95B4emGbtqfQQw@mail.gmail.com>
Date: Thu, 24 Jan 2019 09:07:45 -0500
To: internals@lists.php.net
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] New custom object serialization mechanism
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jan 24, 2019, at 8:02 AM, Nicolas Grekas wrote:
> 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

Given that these methods would not be producing/consuming strings but a de-classed representation of the object, I agree that it's closer to "normalize" as Symfony uses the term.  We don't have to use that name specifically but something other than serialize/deserialize seems logical.

Also, that in turn suggests that the same mechanism could be leveraged for formats other than the C (or 0?  It's referred to both ways in the RFC) format we all know and grudgingly accept.  Eg, it feels an awful lot like JsonSerializable (which is for serialize only, but also returns an array), and I can definitely see uses for a standard intermediary format that could be encoded to C-serialized, JSON, or XML, or whatever else.  Is there some way that we could allow other systems to hook into it cleanly, such that it becomes a common intermediary format for a variety of stringified formats?

--Larry Garfield