ES3.1 questions and issues
erights at gmail.com
Tue Mar 17 21:27:04 PDT 2009
On Tue, Mar 17, 2009 at 6:56 PM, Allen Wirfs-Brock
<Allen.Wirfs-Brock at microsoft.com> wrote:
> In all other Array.prototype functions (and some other places) where similar possibilities exist, I have a situational appropriate variation of a sentence such as "The final state of O is unspecified if in the above algorithm any call to the [[ThrowingPut]] or [[Delete]] internal method of O throws an exception."
Oh. I see that now. Searching, I see it in
I could find no other examples.
I think the inclusion of "map" is a mistake. Map does not mutate O.
For the others, I think "unspecified" is way too broad.
1) These methods must not modify any frozen properties.
2) The only values they may write into these properties should be
those that might have been written had the specified algorithm been
followed up to the point that the error was thrown. Otherwise, a
conforming implementation could react to a failure to pop by writing
the global object or your password into the array.
3) Is there any reason for this looseness at all? If you simply leave
out this qualifier, then the reading of these algorithms consistent
with the rest of the spec is that the side effects that happened up to
the point of the exception remain, while no further side effects
happen. That assumption is pervasive across all other algorithmic
descriptions in the spec. I think we should just drop this qualifier.
Text by me above is hereby placed in the public domain
More information about the Es-discuss