FW: JSON.stringify replacer array semantics
douglas at crockford.com
Tue Jun 9 18:02:52 PDT 2009
Allen Wirfs-Brock wrote:
> Still looking for some consensus on the issue at the end of Doug's message...
>> -----Original Message-----
>> From: Douglas Crockford [mailto:douglas at crockford.com]
>>> 1) should the content of an replacer array be copied at the start of
>> stringify such that it can't be side-effected during stringify
>> processing? Oliver claims that FF 3.5 does such an internal copy and
>> that json2.js also does so. IE8 does not make a copy and my reading of
>> json2.js (pulled today from json.org) disagrees with Oliver's (I think
>> it doesn't copy).
>>> However, making a copy does seem like a reasonable thing to specify.
>> If I could have written json2.js using the ES5 language, I would have
>> Object.keys, not for..in, to obtain the keys. I think it would be good
>> to avoid
>> the side effect hazard that for..in is subject to, particularly in the
>> of mutating getters.
> I've updated my draft to make a side-effect safe list early in stringify.
>>> 2) should ToString be applied to the elements of an replacer array?
>>> Currently this is not done in the ES5 spec. Oliver reports that FF
>> 3.5 does
>>> IE8 does not. json2.js does not. Is this a reasonable departure
>> json2.js implementation?
>> It seems like an unnecessary step to me. Perhaps it would be better to
> Throwing seems inconsistence with all the other rounded corners and outlet protectors that we provide in this function. I think that the two plausible alternatives are to either ignore non-string whitelist values (this is what IE8 and json2.js currently do) or to apply ToString to each whitelist value (which is apparently what FF3.5 does)
I don't like the ToString thing because it can produce useless keys like
"[object Object]" and stuff like that, although it does useful things to
numbers. I am ok with saying that it ignores values that are not strings and
More information about the es5-discuss