It seems to me that you can get the desired behavior even without exposing an internal "generic maximum length" method by simply arranging so that the mutations happen to the largest index first. This effectively ensures that the exception precedes mutation.
This spec trick should be applicable to any generic mutation method, using temporary helpers if needed if the maximum affected index is not immediately apparent from the parameters. Implementers can use in-place update and compensating mutations on exception, regardless of the spec mechanism used to ensure mutations are not visible upon exception. --scott On Mon, Oct 27, 2014 at 12:09 PM, Allen Wirfs-Brock <[email protected]> wrote: > > On Oct 26, 2014, at 8:58 PM, Brendan Eich wrote: > >> Allen Wirfs-Brock wrote: >>> Arguably a design bug, rather than a spec. bug. But I'm assuming that who >>> ever originally wrote up these algorithms were being intentional about such >>> things. >> >> Design, vs. accidental. Spec, vs. implementation. Potato, Potahtoe :-P. >> >> I think we should fix 'em as we find them, if implementations do not agree >> (and they don't usefully agree here). > > I probably wasn't clear about the central issue: > > unshift and other array methods are generic methods that work the same on any > object that has a 'length' property and "array index" properties. When > implemented as currently specified they produce consistent predictable > results across for any such object, even if specified error conditions occur. > > There are many ways that a particular kind of "array-like" object can > constrain their 'length' property. There could be limits built into > [[Get]]/[[Set]] (this is how exotic Arrays work), or the 'length' property > might be readonly, or the 'length' property might be an accessor property > that constrains the length value algorithmically, or the object might be a > Proxy whose handler does whatever. > > Given all of these alternatives, we currently don't have any single generic > way to predetermine if 'length' extending operations such as unshift/splice > will run into 'length' restrictions in the course of executing their generic > algorithm. We might invent such a thing (perhaps a @@maxLength property). > But that isn't a bug fix, that is a significant design change. > > Allen > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
