I just want to point out a set of changes that will be in this week's ES3.1 draft and see if there are any contrary thoughts about the changes.
Many of the algorithms that define the Array.prototype functions make extensive use of [[Put]] and [[Delete]] to move around the properties of an Array (or, since they are generic, any object with array indexed properties). As I recently reviewed these algorithms I began to think about what their behavior should be if they encounter a property is this non-writable, or non-deletable, or if they needed to create a property on an object that is non-extensible. In ES3, this was not an issue as there was no way for ECMAScript code to set the necessary attributes that would result in this circumstance. However, with reified property attributes in ES3.1 this can and will occur. As originally codee for ES3 (or whatever) the algorithms would silently ignore any [[Put]] or [[Delete]] that was blocked by an attribute setting because that is the default non-strict mode behavior of those internal methods. When the algorithms completed, the array object would be silently left in some state that was neither its initial state nor the state promised by the function. This seemed to me to be a significant potential bug farm. The fix I made to these algorithms was to convert every [[Put]] to a [[ThrowingPut]] with the throw parameter set to true. I also explicitly set the throw parameter to true for all [[Delete] calls. With these changes, the algorithms will throw a TypeError if any step of the algorithm cannot be carried out because of the attribute settings of an individual property or the [[Extensible]] property of the object. If such an error occurs, the array object may (probably will) be left in some partially updated state. However, the exception should help with the early detection of such problems. In addition to the Array.prototype methods I also made this change to a few other section 15 functions that appeared to also be susceptible to this problem. Let me know if you have any concerns about this approach. Allen
_______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
