toJSONString

[Bob Ippolito]

On 4/13/07, Douglas Crockford <douglas at crockford.com> wrote:
> The only complaints I have received about json.js is
> that the methods are not dontenum. That will be fixed
> as a result of the current effort.
>
> I don't see that the level of danger here is anything
> to worry about. A JSON receiver will not be corrupted
> should someone accidently miscode a toJSONString
> method. Such accidents are unlikely because the
> default methods are right and the method is easy to
> write.
>
> If we are concerned about intentional misencodings,
> then the focus of worry is entire misplaced. A toJSON
> interface allows falsification of data, which is a
> much bigger problem. And the current nature of
> JavaScript and the DOM provide absolutely no defense
> against malicious code, should it get on the page.

I think you're missing the point. If you're writing a custom
toJSONString, then by definition of JSON what you're really doing is
just returning a JSON encoding of some other object. A typical
toJSONString method would therefore look like this:

function toJSONString() {
    var other = {foo: this.foo, bar: this.bar};
    return other.toJSONString();
}

Why force a call to toJSONString? It doesn't make any sense at all.
There's no use case for piecing together a string manually that
results in a valid JSON document.

The toJSON proposal removes the chance for creating invalid documents
*and* results in less code, in all cases. What's your problem with it?
I simply don't understand how you could possibly prefer toJSONString
as the method for extension.

-bob