toJSONString

[Robert Sayre]

On 4/13/07, Bob Ippolito <bob at redivi.com> wrote:
> > On 4/13/07, Douglas Crockford <douglas at crockford.com> wrote:
> >
> > 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.

I think you underestimate the pressure that will be placed on server
implementors should cross-domain JSON become popular. Right now, the
threat is low because JSON requests only need to interoperate with a
small number of server implementations (usually just one). Any
Internet protocol will eventually face this problem, whether it be
form-encoded traffic or HTTP authentication.

The race to the bottom will happen with character sets and field
values anyway, but I see no reason to add syntactic grief from any
random web page.

> 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.

This claim seems correct to me. I think toJSON seems like the better choice.

>
> The toJSON proposal removes the chance for creating invalid documents
> *and* results in less code, in all cases.

This claim also seems correct.

-- 

Robert Sayre