JSON decoding

Brendan Eich brendan at mozilla.com
Thu Nov 2 14:06:38 PST 2006

On Oct 26, 2006, at 8:41 AM, Bob Ippolito wrote:

> I think the current proposal is dangerous. I don't think it's an API
> that people will use correctly. Having to generate an entirely new
> object graph before encoding really bites for performance and ease of
> use.

Having to generate a new object graph is required either way, Doug's  
or Bob's:

Doug's: transform an object graph g to JSON-ready object graph jrg,  
then use jrg.toJSONString().

Bob's: use a JSONEncoder to process g, which where it needs to  
transform from non-JSON-ready object subgraph sg to JSON-ready graph  
jrsg evaluates jrsg = sg.toJSON().  The encoder then uses  

In practice, these are just different ways of doing the same work,  
because no one using Doug's way would copy the entire graph, given  
that some of it is JSON-ready as posited in the toJSON case (Bob's  
way).  So Doug's way ends up being "for each sub-graph sg that's not  
JSON-ready, override toJSONString with a function that transforms sg  
to JSON-ready jrsg and return jrsg.toJSONString()."

Ok, so what's really at stake here: whether users have

a) the opportunity to return any old string by overriding toJSONString;
b) the requirement to override toJSONString for each sub-graph sg  
that's not JSON-ready.

Bob's way, there's a b' counterpart to b:

b') define (not override) toJSON for each sub-graph sg that's not  

Bob's way doesn't have the (a) hazard.  His (b') is different too in  
how it requires defining a method, toJSON, that does not override a  
standard method on a prototype object.  So the JSONEncoder only has  
to look for toJSON and use it if it's defined; otherwise it can use a  
non-overrideable internal method to encode values.

Doug's way follows the toString pattern, and since non-JSON-ready  
values in objects and arrays are skipped when encoding, it usually  
does what is meant.  Or we can hope that it does what is meant.  Or  
something; I'm not sure what JSON users want, so I'll stop guessing.  
In any event, it's simple by one measure: a single toJSONString  
method pattern, a method on various prototypes that can be overridden  
to customize, instead of JSONEncoder and an optional toJSON.

> You also over-estimate the difficulty of implementing a "toJSON"
> method instead of "toJSONString". It's really not that hard,
> seriously, I've written at least two JSON encoders that do it.

It's clear from the above that (b) and (b') are about the same amount  
of work.

> It sounds more like you don't want to change the spec for the sake  
> of not
> having to change it.

Doug is still editing the spec, changing it from what I forwarded, so  
that's not the case.  On the down side from your point of view, the  
spec is changing to match http://www.json.org/json.js in detail.  I'm  
writing again to make sure that we agree on what's different between  
the two proposals ((a) hazard; (b) vs. (b')), and that we include a  
rationale in the final spec for whatever ends up there.

> Also, I've NEVER seen a serialization protocol that does something
> silly like toJSONString. If they offer transformations, it's always
> guaranteed that you get valid output... and the only way to do that is
> to allow the transformation to return a data structure instead of a
> raw stream.

I think everyone gets this point. I agree it's a virtue. It sounds  
like Doug values it less, but I'll let him speak.

Does anyone else have an opinion?


More information about the Es4-discuss mailing list