ES3.1 questions and issues
david.hopwood at industrial-designers.co.uk
Wed Mar 18 15:40:32 PDT 2009
Mark Miller wrote:
> 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.
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 ⚥
More information about the Es-discuss