On Thu, 23 May 2013, Martin Bähr wrote:
one idea is, while encoding the mapping, to take the return value of the callback, and check it against the original mapping (which we should still have, even if we are already halfway done encoding). if the original mapping already has a key that matches the returned string, then throw an error, otherwise allow the key.
Unfortunately, its not that simple. Assume
([ 1 : 0, 2 : 0, 3 : 0 ])
and a callback that always returns ""foo"". ""foo"" would not be found in the mapping and therefore lead to invalid json (the rfc says that duplicate keys should not occur). Most parser will probably either use the first encountered key or the last one. Some will error. The pike one currently uses the last one, since that is easy to implement. The json rfc does not specify _what_ a parser is supposed to do.
Maybe my argument is overly pedantic: Currently, using encode_json() one can already create invalid json. In fact I have been using that regulary to produce javascript, for instance to encode objects as (new SomeClass()).
I guess my opposition to more hooks is that somewhere down the road that callback solution is not flexible enough. In particular your callback might want to encode objects as some string in case they are mapping keys but treat them differently, if they are not. How do you tell the difference? Of course that could be solved by either having two callbacks or passing some kind of flag...
Its seems more reasonable to me to have a limited set of tweaks; in particular since the mapping from pike data types to json is very well defined. Some things can be mapped, others cannot. Everything else has to be transformed first in the same way as it has to be transformed when decoding from json.
arne