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't pass any variable there. So this has BC issue and as it has BC you won't like it. What are then the options? I'm not familiar how this PHP thing is developed. - Do a BC incompatible change in future, will probably need a voting and most probably people won't see the case for it and will not accept it. (as I've already seen the "you're doing it wrong" comments, but I'm not so sure that the dynamic object-relational-mapping that loads references is so stupid, as if it wouldn't do that, then we would have to tell, case by case what to relations load and when. Now it just loads everything but stops at the depth needed. Also somehow we would probably want to say load the first 'parents' reference but not from the next ones, which would mean knowing the depth.). - Do it another way? So that it wouldn't be BC incompatible? How would one do that smart and so that it would be accepted? I don't see good way of going it.. Having some jsonSerializeDepth that gets called if it exists, not jsonSerialize being pretty. Any other ideas? - Fixing json_encode, as there wouldn't be a problem if json_encode's depth would be useful, like limiting the depth to given depth and not going too deep and getting into trouble.. Now the depth is just pretty useless, oh, it's too deep, throw error, not like just limit to this given depth. But changing that would also be BC incompatible. And after thinking why the depth came there https://bugs.php.net/bug.php?id=62369 it just fixed stack overflow. And then if one tries to fix that from json_encode's side then without BC issues it would need some new parameter like boolean $cut = false, which would then make it cut at the depth not like it does now. But that parameter for start seems pretty stupid and don't know how big thing that would be to implement. - Continue using patched json, or just do the whole json encoding thing itself so that the depth is accessible. - Some other way that I didn't think of?
