Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97765
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.182 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <DB5PR0101MB1736F89440F718E955C7A89491660@DB5PR0101MB1736.eurprd01.prod.exchangelabs.com>
References: <DB5PR0101MB1736F89440F718E955C7A89491660@DB5PR0101MB1736.eurprd01.prod.exchangelabs.com>
Date: Sun, 15 Jan 2017 20:49:08 +0000
Message-ID: <CAEKnhAHo4=HhfjnNDJu7M=KHipF9sC4ZZBcUCDjgk7nkUNT+eA@mail.gmail.com>
To: Jani Ollikainen <jani.ollikainen@valve.fi>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114084a2d4afd205462832f9
Subject: Re: [PHP-DEV] Exposing jsonSerialize's depth
From: bukka@php.net (Jakub Zelenka)

--001a114084a2d4afd205462832f9
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 11, 2017 at 8:06 AM, Jani Ollikainen <jani.ollikainen@valve.fi>
wrote:

> Hi,
>
> I've made a pull request where I was asked to start internal discussion
> about it.. The pull request can be found:
> https://github.com/php/php-src/pull/1884
> Which  relates to request I've also made:
> https://bugs.php.net/bug.php?id=72073
>
> For short the thing is:
> "We have objects that do dynamic loading and there might be recursions. We
> could use recursion depth to decide when we want to do dynamic loading and
> when not.
>
> Now there doesn't seem to be any way to know how deep is the json_encode
> process going. If we try to use some level in jsonSerialize it just calls
> one of those, no recursion there.
>
> This could be easily archived by exposing the internal encoder_depth to
> jsonSerialize."
>
> As I don't know any other way to get the depth info from jsonSerialize, as
> it isn't called recursively in PHP side, so adding some static class
> variable and incrementing/decrementing it in jsonSerialize will just not
> work.
>
> Then to why would someone really need that? Well, we have models that uses
> MongoDB as a database (created from MongoDB objects) and the models can
> have references to other models (coming from MongoDB objects). That loading
> will happen dynamically and there might be recursions, but we want
> still to serialize them as we really don't need to go that deep even if
> there is a recursion. This way we can control the depth we are loading new
> objects and
> can avoid recursion happening in jsonSerialize and can get the data we
> need serialized.
>
> If you are thinking why don't you just use the depth option of
> json_encode, well unfortunately it doesn't help. It seems to go too deep
> and get recursion errors and would just later limit the depth it's going as
> my example will show if you try if you run it without patched json.
>
> Any comments/ideas?
>
>

I don't really like this. The reason is that you don't actually modify
JsonSerializable interface for the obvious BC break that it would cause it.
It means that the function just gets this parameter and it kind of raises a
question how we should document it? The solution would be to extend
JsonSerializable with some new interface. However I don't think it's worth
it for such thing. Maybe you should consider to pre-process your data
before passing it to json_encode...

Cheers

Jakub

--001a114084a2d4afd205462832f9--