Yuh-Ruey Chen maian330 at
Sat Apr 21 22:06:59 PDT 2007

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

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

More information about the Es4-discuss mailing list