FW: JSON.stringify replacer array semantics

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Tue Jun 9 17:39:17 PDT 2009

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
>from the
>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) 
My current working draft ignores them although I think a reasonable case could be made that ToString'ing them is the more JavaScript idiomatic thing to do.  However, I'm not doing to change it to that unless we get more people advocating for that resolution.


More information about the es5-discuss mailing list