On Mon, May 11, 2009 at 11:47, Allen Wirfs-Brock <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
