Mark Miller wrote: > On Tue, Mar 17, 2009 at 6:56 PM, Allen Wirfs-Brock > <[email protected]> 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 > Array.prototype.{pop,push,reverse,shift,splice,unshift,map} > > 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.
I agree completely, and particularly with points 1) and 2). There should be very good reasons to make behaviour unspecified or implementation-defined; here there is not. -- David-Sarah Hopwood ⚥ _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
