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
