2017-01-16 9:19 GMT+01:00 Jani Ollikainen <jani.ollikai...@valve.fi>:
> 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.
>
That BC break: https://3v4l.org/L1u7q
Regards, Niklas
> 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.
>
>
