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
Having to generate a new object graph is required either way, Doug'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
> 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