toJSONString
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.
I have to agree with the others: the toJSON proposal retains the extensibility of customizable toJSONString's yet is guaranteed to result in valid JSON strings. What advantage does a customizable toJSONString have over a customizable toJSON + readonly toJSONString? You can still "falsify data" or "malicious code" just as easily with customizable toJSONString's.
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.
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.