On Mon, Jan 16, 2017 at 8:19 AM, Jani Ollikainen <jani.ollikai...@valve.fi>
wrote:
> 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] )
>
That's not what is implemented. You just call jsonSerialize with an extra
parameter and basically create a contract that is not specified by the
interface. As you can see from the example that Niklas sent, you can't just
add an optional parameter to the interface method as it would be a BC break.
Cheers
Jakub
