RE: [PHP-DEV] Exposing jsonSerialize's depth
| From: | Jani Ollikainen | Date: | Mon, 16 Jan 2017 08:19:00 +0000 |
| Subject: | RE: [PHP-DEV] Exposing jsonSerialize's depth | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-97776@lists.php.net to get a copy of this message | ||
Hi,
> 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...
What BC break are you talking about? There is no need for using the parameter in old codes. Even if
we pass that depth to jsonSerialize doing something like:
"public function jsonSerialize() {...}" will still work without any problems.
And how would you document it it? Like any other.. if there now is: http://php.net/manual/en/jsonserializable.jsonserialize.php
abstract public mixed JsonSerializable::jsonSerialize ( void )
This function has no parameters.
Then it would just be:
abstract public mixed JsonSerializable::jsonSerialize ( [integer $depth] )
Parameters:
depth
Depth of the current json_encode -call.
New interface would also be good, but as you said it, it doesn't seem to be worth the trouble.
Well, and what do you think how much does going pre-processing slow the code versus without need for
pre-processing? That really doesn't sound option to me.