FW: JSON.stringify replacer array semantics

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Mon Jun 8 14:16:24 PDT 2009

Doug and Rob, 
Did you have any opinion on these two item (see below):

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.

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 this.  IE8 does not.  json2.js does not.  Is this a reasonable departure from the json2.js implementation?

Rob, I assume you've voted with your code...


-----Original Message-----
From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Allen Wirfs-Brock
Sent: Friday, June 05, 2009 11:25 AM
To: Oliver Hunt; es-discuss at mozilla.org
Cc: Rob Sayre; Douglas Crockford
Subject: RE: JSON.stringify replacer array semantics

Thanks, these are good observations. It's useful to have fresh eyes looking at this stuff.

I believe the intent was that step 5.a of JO should have the same effect as the json2.js code you quoted. However, if that is the case it is missing the filtering to include only primitive string values.

I'm sympathetic to the argument that rather than filtering for string values it would be better to apply ToString to the replacer elements. However, that would be a departure from what json2.js does.  IE8 also currently matches the json2.js in this regard. FF?? The most likely use case I can think of for non string replacer array values would be passing an array like [2,4,6,8] to select only some elements of an array that is  being serialized.  However, since the replacer whitelist isn't used in JA this really isn't a real use case.  That argument pretty much convinced me that there isn't really much value in support non-string values in replacer arrays and it is probably best to stick with the json2.js behavior. Doug and Rob, do you have any thoughts on this?

The effect of a side-effect of the stringify algorithm mutating the replacer array is as well defined as any other side-effect sensitive aspect of the algorithm, if the entire stringify algorithm is strictly implemented as specified. A strict interpretation of the current specification requires that the List in JO step 5.a gets recreate on each use of JO. So side-effects that modify the replacer array would result in different List contents.  I think it probably is a good idea to move step 5.a into the top level stringify algorithm so that the List is only generated once before any possible side-effect producing operations.  This may be a variance from what the IE8 and FF implementations are currently doing (I haven't yet crafted a test for this that produces the necessary side-effects) but I don't think that in the short term the difference is likely to impact anyone and for the long term it is probably best to preclude the possibility of side-effecting replacer arrays.

(Note that we use Lists within the algorithms rather than "new array" because as an internal specification data type Lists are not sensitive to side-effects induced via modifications to Array.prototype)


>-----Original Message-----
>From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
>bounces at mozilla.org] On Behalf Of Oliver Hunt
>Sent: Thursday, June 04, 2009 4:02 PM
>To: es-discuss at mozilla.org
>Subject: JSON.stringify replacer array semantics
>The spec for JSON doesn't describe the exact behaviour of the replacer
>argument to stringify when the replacer is an array.  The relevant
>text (from 15.12.3) is
>If Type(replacer) is object and the [[Class]] internal property of
>replacer is "Array", then
>     Let K be an internal List consisting of the values of those
>properties of replacer that have array index names. The elements of
>the list are in ascending array index order.
>As the replacer array may contain any sequence of values we need to
>specify the acceptance, conversion, and conversion timing for each
>element.  The spec doesn't really specify these details at all, saying
>only that replacer may be an array of strings.
>Two issues that need to be clarified (that i can see):
>    * What happens if the replacer array is modified during
>    * What happens to non-string primitives are in the replacer array?
>json2.js basically seems to do something akin to the following if
>replacer is an array
>    givenReplacer = replacer;
>    replacer = [];
>    var length = replacer.length;
>    for (var i = 0; i < length; i++) {
>        if (typeof givenReplacer[i] === "string")
>            replacer.push(givenReplacer[i]);
>    }
>This resolves the above issues by making a copy of the array (thus
>isolating it from mutation of the replacer array), and resolves the
>non-string property issue by just ignoring any non-string values.  I
>believe it would be more consistent with ECMAScript to perform
>[[ToString]] conversion instead of filtering non-string values, but if
>we do that we need to specify when the [[ToString]] conversion should
>occur.  I believe that at the beginning of the stringify algorithm,
>probably just before what is currently step 7 (where the wrapper is
>7. If Type(replacer) is object and the [[Class]] internal property of
>replacer is "Array", then
>     a. Let oldReplacer be replacer
>     b. Let replacer be a new array
>     c. Let len be the result of calling the [[Get]] internal method
>of oldReplacer with argument "length"
>     d. Let index be 0
>     e. Repeat while index < len
>         i. Let prop be the result of calling the [[Get]] internal
>method of oldReplacer with argument index
>         ii. Let prop be the result of calling the method ToString(prop)
>         iii. if prop is not undefined
>             A. Call the [[Put]] internal method of replacer with
>arguments index and prop
>         iv. Increment  index by 1
>Remaining steps 7, 8, and 9 move to 8, 9,  and 10
>es-discuss mailing list
>es-discuss at mozilla.org

es-discuss mailing list
es-discuss at mozilla.org

More information about the es5-discuss mailing list