JSON decoding

Bob Ippolito bob at redivi.com
Thu Nov 2 14:50:33 PST 2006

On 11/2/06, Brendan Eich <brendan at mozilla.com> wrote:
> 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
> jrsg.toJSONString().
> 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
> JSON-ready.
> 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.

If an implementation that does "toJSON" is wanted, then I could
extract one from MochiKit.Base.serializeJSON...


More information about the Es4-discuss mailing list