Hi,
> Even if you leave the interface as is and just pass the parameter
> additionally, it could have been extended by users just like in your example
> and pass a
> wrong value then.
Yes, it might. I don't come up an idea why, but maybe someone has had a reason,
as the json_encode calling won
>
> >> 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
>
> A
Hi.
>> 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
And
On Mon, Jan 16, 2017 at 8:19 AM, Jani Ollikainen
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
>
2017-01-16 9:19 GMT+01:00 Jani Ollikainen :
> 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 ho
Hi,
> This looks like a hack covering for deficient design. Having objects that
> look differently depending on hidden parameters without anybody explicitly
> modifying them is a recipe for very hard to track bugs. I don't think we
> should encourage this.
>
> There are ways to present serialize
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
Hi!
> 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.
>
This looks like a hack covering for deficient design. Having objects
that look differently depending
On Wed, Jan 11, 2017 at 8:06 AM, Jani Ollikainen
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.p
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
10 matches
Mail list logo
