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
