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.
