Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100920
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.175 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
Date: Mon, 23 Oct 2017 20:20:30 -0400
Message-ID: <CAESVnVpUqpLpKW5X2k7v-nMUxCUhBPQ6P0tEBP9_zNdo63309w@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: json(Raw)Serializable?
From: pollita@php.net (Sara Golemon)

https://bugs.php.net/bug.php?id=75400 is asking for a version of
JsonSerializable which doesn't involve deserializing/reserialzing
round trips when a chunk of JSON is known in advance.

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
  }
}

Perhaps with the stipulation that if jsonRawSerialize() returns null,
we'd fallback on jsonSerialize().  Any other non-string results in an
encoding error.

-Sara