toJSONString

[Yuh-Ruey Chen]

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.

Douglas Crockford 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.
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>
>