Array methods applied to strings

[Erik Arvidsson]

On Mon, May 11, 2009 at 11:47, Allen Wirfs-Brock
<Allen.Wirfs-Brock at microsoft.com> wrote:
> The motivation for replacing [[Put]] and [Delete]] calls with throwing versions in the Array prototype functions was to provide proactive notification when these algorithms were applied to arrays (or other objects) where the existence of non-writable properties might result in violations of the normally expected post conditions of the algorithms. Note that this had not been a problem for ES3 because ES3 provided no programmatic way to set the readonly attribute and the only built-in readonly property that might impact these algorithms was the length property of strings.
>
> Arguably this situations comes up in ES3 only when these functions are applied to String instances but note that manifesting array index properties on String objects is not specified by ES3 so strictly speaking this is not an ES3 compatibility issues but a compatibility issues relative to implementations that have extended ES3 with such String properties. Also note that IE (including IE8, although it has some SunSpider compatibility hacks in this area) has never supported array-like indexing of String objects.  Hence, it is debatable whether this is truly a "web compatibility" issue, as calling of these functions on Strings does not work identically across all widely used browsers.
>
> When we talked about this in the ES3.1 working group we didn't specifically think about strings.  Instead we were thinking that reified properties attributes creates a hazard where these functions might be inadvertently be applied to Arrays or (or other objects) with non-writable properties and that in such situations it would be better to throw an exception (making the programmer aware of a likely bug) rather than allowing the functions to silently complete but leaving objects in a state that violates the expected post conditions of the functions.
>
> In reexamining this issue now, I started out thinking we had made a mistake but after reconstructing the login chain that lead to this decision I find myself "on the fence" and perhaps leaning a bit towards keeping the exceptions.  The choice is between avoiding creating a new category of silent bugs or maintaining compatibility with a not universally implemented extension to ES3.
>
> How often are these functions really applied to strings? The use case for applying pop to strings seemed reasonably compelling but as I look at most of the other array functions I don't see that they make much sense in the presence of non-writable elements.
>
> The other alternative, would be to special case the algorithms for these functions such that they do not throw when the this object is a string object but throw in all other scenarios.  This is actually a pretty trivial change to make to the specification that would maintain compatibility with existing implementations that support string indexing  but still throw in all other cases (including Arrays) where non-writable properties would result in violations of the expected post conditions.

I think the right solution would be to use a non throwing [[Put]] for
the Array methods for backwards compatibility.  NodeList and Arguments
are the common array like structures that people use the array
generics for and I can see other things like ImageData getting more
common in the near term future. Special casing String will not help
the common case.

-- 
erik