You're correct about map. It had previously used [[ThrowingPut]] rather than [[DefineOwnProperty]].
Over specification of non-essential requirements is not necessarily beneficial. I'm reluctant to over spec. these algorithms for these error cases. As section 5.2 says an implementation may choose to use more efficient algorithms and the necessity to exactly match a complex state in an error situation makes it much more difficult to create more efficient algorithms. I would sooner have non-error cases run faster than to have precisely specified results for improbable error conditions such as applying these functions to an array where some arbitrary set of elements are non-writable or non-delectable. It actually bothers me that the algorithms imply a particular sequence of element access and hence implies a particular order of side-effects if any accessed elements are accessor properties. It might actually be better if the other array algorithms said something similar to sort's "Perform an implementation-dependent sequence of calls to the [[Get]] , [[ThrowingPut]], and [[Delete]]". Nobody should intentionally writes code that depends upon the order of side-effects of these operations. Saying the result is unspecified is not open an invitation for implementation to expose the user's password or to do anything else that would not be normally part of one of these algorithms. No rational implementation is going to do something like that. "Unspecified" is more a warning to programmers that if an exception is thrown they should not depend upon the state of the involved objects Allen _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
