Array methods applied to strings

[Allen Wirfs-Brock]

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.

Thoughts??

Allen         

>-----Original Message-----
>From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
>bounces at mozilla.org] On Behalf Of Erik Arvidsson
>Sent: Monday, May 11, 2009 8:41 AM
>To: James Graham
>Cc: es-discuss at mozilla.org
>Subject: Re: Array methods applied to strings
>
>The old behavior is indeed needed for web compatibility. All Array
>methods are supposed to be generic and I know js libraries use them
>heavily on NodeLists and ther non Array objects.
>
>ES5, 15.4.4.6, has no type check by itself but it is calling
>[[ThrowingPut]] which will throw when called on a String. It seems
>like step 5.d needs to be changed to a [[Put]] instead?
>
>I assume we have to update all the other Array methods as well?
>
>On Mon, May 11, 2009 at 05:16, James Graham <jgraham at opera.com> wrote:
>> It seems that ES5 throws a TypeError for constructs like
>>
>> Array.prototype.pop.call("abc")
>>
>> whereas current implementations (and, I think ES3, but I didn't check
>that
>> closely) will return "c".
>>
>> Is this change intentional? There seems to be a note in the
>compatibility
>> appendix that is about a similar, but not quite identical issue (or
>maybe it
>> is identical and I have misunderstood). Are there grounds to be
>confident
>> that the old behavior is not needed for web compatibility?
>>
>> Apologies if I have overlooked something or misunderstood something.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
>--
>erik
>_______________________________________________
>es-discuss mailing list
>es-discuss at mozilla.org
>https://mail.mozilla.org/listinfo/es-discuss