Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100933
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.180 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <b0942929-b7a4-7be8-674f-982fdf40a6b7@gmail.com>
References: <CAESVnVpUqpLpKW5X2k7v-nMUxCUhBPQ6P0tEBP9_zNdo63309w@mail.gmail.com>
 <b0942929-b7a4-7be8-674f-982fdf40a6b7@gmail.com>
Date: Tue, 24 Oct 2017 15:06:42 +0100
Message-ID: <CAEKnhAE4EsPSybiZKAmBn9kqTTbT1Y3EfJduaRfQc5FUkvhdfg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="f403045c03bae2a80d055c4b72b3"
Subject: Re: [PHP-DEV] json(Raw)Serializable?
From: bukka@php.net (Jakub Zelenka)

--f403045c03bae2a80d055c4b72b3
Content-Type: text/plain; charset="UTF-8"

On Tue, Oct 24, 2017 at 7:32 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > It's not terribly unreasonable IMO, but before I just writeup the RFC
> > as described (jsonRawSerialize taking preceedence over jsonSerialize),
> > I thought I'd ask for opinions on the specifics.
> >
> > In psuedo-code:
> >
> > if (is_object($obj)) {
> >   if ($obj implements JsonRawSerializable) {
> >     // use $obj->jsonRawSerialize() as is.
> >   } elseif ($obj implements JsonSerializble) {
> >     // use json_encode($obj->jsonSerialize())
> >   } else {
> >     // Serialize the object's public properties as a key/value map
> >   }
> > }
>
> I'm not sure I feel very comfortable with having specialized serialize
> interfaces for every format, yet more with having more than one of them.
>
> There's also validation problem - if we don't ensure this is valid JSON,
> then whole serialization setup is broken, and who knows which
> consequences this will bring.
>
>
I fully agree with this. In addition to validation we wouldn't be able to
assure that options work as well. For example consider options
like JSON_HEX_*, JSON_PRETTY_PRINT, JSON_UNESCAPED_SLASHES,
JSON_FORCE_OBJECT, JSON_PRESERVE_ZERO_FRACTION, JSON_UNESCAPED_UNICODE and
some other encode options.

I think this is not a good idea and can cause many problems. So -1 from me.

Cheers

Jakub

--f403045c03bae2a80d055c4b72b3--