But Function.prototype.apply doesn't preserve holes. On Oct 3, 2011 6:50 AM, "Sean Eagan" <[email protected]> wrote: > So I realized hole preservation is actually relevant in both array > structuring and destructuring. Array structuring and destructuring > ellipses forms are both specified in the draft spec to preserve holes. > > Argument lists are merely array structuring patterns, and parameter > lists are merely array destructuring patterns, so to me, their syntax > and semantics should be the same. Thus, ellipses forms for argument > lists and parameter lists should be hole preserving as with array > structuring / destructuring. Take this example: > > // rest has 98 holes > [a, b, ...rest] = [...Array(100)]; > > // extract into function form -> > > // rest should still have 98 holes, not 98 undefined's > (function(a, b, ...rest){})(...Array(100)); > > On Fri, Sep 30, 2011 at 8:41 AM, Sean Eagan <[email protected]> wrote: >> On Thu, Sep 29, 2011 at 2:53 PM, Allen Wirfs-Brock >> <[email protected]> wrote: >>> It seems highly desirable that we preserve the existing semantics of arguments >> >> I agree, for backward compatability. >> >>> and that: >>> function foo(...args) { >>> assert(length.arguments === length.args}; >>> for (let i in arguments) assert(arguments.hasOwnProperty(i) === >>> args.hasOwnProperty(i) && arguments[i] === args[i]); >>> } >> >> I disagree, rest parameters are intended as an eventual permanent >> replacement for `arguments`, and thus it is more important to make >> them have the correct and consistent with array literal spread element >> hole preservation behavior, than consistency with what will be the >> legacy `arguments` to aid a one time migration to rest parameters. To >> illustrate the problems I see with filling holes in rest parameters, >> assume we are working with a holey array: >> >> let holeyArray = []; >> holeyArray[99] = true; >> >> and some code which uses it: >> >> let spreadTarget = [a, ...holeyArray, b]; // 99 holes >> holeyArray.forEach(expensiveOperation); // 1 iteration >> >> at some point we decide to abstract this code into functions: >> >> function f(...arr) { >> return [a, b, ...arr]; >> } >> function g(...arr) { >> arr.forEach(foo); // holes now filled leading to extra iterations >> } >> ... >> let spreadTarget = f(...holeyArray); // 99 unwanted `undefined`s now >> g(...holeyArray); // 100 iterations now >> >> >>> regardless of how foo was called. In other words, baz(...bar) and >>> baz.apply(undefined,bar) should always produce the same effect. >> >> I agree since one form is not intended to replace the other. The >> effect IMHO should be that if baz uses `arguments`, holes are not >> preserved for backward compatability, but if baz has upgraded to rest >> parameters, then holes are preserved. >> >> >> Also, I think not filling holes can be optimized since the `undefined` >> values don't need to be added to the rest parameter argument. >> >> Thanks, >> Sean Eagan >> > > Thanks, > Sean Eagan > _______________________________________________ > 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
